[Geoserver-devel] REST service to list fonts available in java runtime

Jose_Garcia · October 14, 2010, 6:56am

Hi

I created a new issue in JIRA (GEOS-4175) with a patch to add a REST service to return the list of fonts avalaible in the java runtime in the server.

Would be nice if you can review so can be improved (sorry i’m quite new to GeoServer code and for sure the code can be improved) and when seem ok integrate SVN for nexts releases.

Thanks and regards,
Jose García

Andrea_Aime4 · October 14, 2010, 7:31am

On Thu, Oct 14, 2010 at 8:56 AM, jose garcia <josegar74@anonymised.com> wrote:

Hi

I created a new issue in JIRA (GEOS-4175) with a patch to add a REST service
to return the list of fonts avalaible in the java runtime in the server.

Would be nice if you can review so can be improved (sorry i'm quite new to
GeoServer code and for sure the code can be improved) and when seem ok
integrate SVN for nexts releases.

The patch you've provided implies changes to the catalog api.
I cannot say for certain, but such a change is unlikely to work for
the stable series
(I see that you've developed it against 2.0.2).
I'm also not sure why the catalog should be involved in the first
place, the list
of fonts is known to the java runtime itself, so there is no need to
re-catalogue
the fonts inside the GeoServer API, no?

From another point of view, the data directory is meant to be movable from

one system to another: but the list of font won't be the same on the
two systems,
so it does not make sense to store the list of fonts inside the GeoServer data
directory either.

Also, in order to be accepted a patch must be developed for trunk, since that's
where it has to go first (and then be eventually backported if it does not break
the API).

If you look in trunk there is also the transparent ability to use any font that
has been dropped into the styles directory, with some code that registers
the fonts found there in the GeoTools FontCache.
Ideally we should extend that class a bit more to allow listing the fonts
known to the rendering subsystem (that api change we can also make in
a stable series as FontCache is a class, not an interface).

So what about this:
* the catalog part of the patch gets removed
* we add a method in FontCache to list the known fonts
* the rest part of the patch gets moved to use the FontCache as the
source of known fonts

Cheers
Andrea

--
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

Jose_Garcia · October 14, 2010, 7:50am

Hi Andrea

Thanks for the comments. I’ll check to fix these things and provide a patch and sorry but my knoweledge of GeoServer code is quite limited for now.

Regards,
Jose García

On Thu, Oct 14, 2010 at 9:31 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Oct 14, 2010 at 8:56 AM, jose garcia <josegar74@anonymised.com> wrote:

Hi

I created a new issue in JIRA (GEOS-4175) with a patch to add a REST service
to return the list of fonts avalaible in the java runtime in the server.

Would be nice if you can review so can be improved (sorry i’m quite new to
GeoServer code and for sure the code can be improved) and when seem ok
integrate SVN for nexts releases.

The patch you’ve provided implies changes to the catalog api.
I cannot say for certain, but such a change is unlikely to work for
the stable series
(I see that you’ve developed it against 2.0.2).
I’m also not sure why the catalog should be involved in the first
place, the list
of fonts is known to the java runtime itself, so there is no need to
re-catalogue
the fonts inside the GeoServer API, no?

From another point of view, the data directory is meant to be movable from
one system to another: but the list of font won’t be the same on the
two systems,
so it does not make sense to store the list of fonts inside the GeoServer data
directory either.

Also, in order to be accepted a patch must be developed for trunk, since that’s
where it has to go first (and then be eventually backported if it does not break
the API).

If you look in trunk there is also the transparent ability to use any font that
has been dropped into the styles directory, with some code that registers
the fonts found there in the GeoTools FontCache.
Ideally we should extend that class a bit more to allow listing the fonts
known to the rendering subsystem (that api change we can also make in
a stable series as FontCache is a class, not an interface).

So what about this:

the catalog part of the patch gets removed

we add a method in FontCache to list the known fonts

the rest part of the patch gets moved to use the FontCache as the
source of known fonts

Cheers
Andrea

–

Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Tim_Schaub2 · October 14, 2010, 4:36pm

I haven't applied this patch to try it out, so excuse me if these questions aren't relevant.

Glancing at the patch, it looks like an HTML list is returned for GET requests to the fonts resource. Would alternate content types be possible? A JSON representation would be particularly useful.

I assume a font has both a unique identifier (name?) and a human friendly title (fontName?). Are both of these provided? If not, this would be useful information for clients that want to let users choose a font based on the title and use the identifier for communication with GeoServer.

Again, I'm not sure what you have already implemented, but the following minimal JSON representation would be useful from a client perspective.

{
     "fonts": [
         {
             "id": "foo",
             "name": "Foo"
         }, {
             "id": "bar",
             "name: "Bar"
         }
     ]
}

(And links to other resources & representations would be a bonus.)

Apologies if this is not entirely relevant given what you have done.

Tim

On 10/14/10 1:50 AM, jose garcia wrote:

Hi Andrea

Thanks for the comments. I'll check to fix these things and provide a
patch and sorry but my knoweledge of GeoServer code is quite limited for
now.

Regards,
Jose García

On Thu, Oct 14, 2010 at 9:31 AM, Andrea Aime
<andrea.aime@anonymised.com <mailto:andrea.aime@anonymised.com>> wrote:

    On Thu, Oct 14, 2010 at 8:56 AM, jose garcia <josegar74@anonymised.com
    <mailto:josegar74@anonymised.com>> wrote:
     > Hi
     >
     > I created a new issue in JIRA (GEOS-4175) with a patch to add a
    REST service
     > to return the list of fonts avalaible in the java runtime in the
    server.
     >
     > Would be nice if you can review so can be improved (sorry i'm
    quite new to
     > GeoServer code and for sure the code can be improved) and when
    seem ok
     > integrate SVN for nexts releases.

    The patch you've provided implies changes to the catalog api.
    I cannot say for certain, but such a change is unlikely to work for
    the stable series
    (I see that you've developed it against 2.0.2).
    I'm also not sure why the catalog should be involved in the first
    place, the list
    of fonts is known to the java runtime itself, so there is no need to
    re-catalogue
    the fonts inside the GeoServer API, no?
     >From another point of view, the data directory is meant to be
    movable from
    one system to another: but the list of font won't be the same on the
    two systems,
    so it does not make sense to store the list of fonts inside the
    GeoServer data
    directory either.

    Also, in order to be accepted a patch must be developed for trunk,
    since that's
    where it has to go first (and then be eventually backported if it
    does not break
    the API).

    If you look in trunk there is also the transparent ability to use
    any font that
    has been dropped into the styles directory, with some code that
    registers
    the fonts found there in the GeoTools FontCache.
    Ideally we should extend that class a bit more to allow listing the
    fonts
    known to the rendering subsystem (that api change we can also make in
    a stable series as FontCache is a class, not an interface).

    So what about this:
    * the catalog part of the patch gets removed
    * we add a method in FontCache to list the known fonts
    * the rest part of the patch gets moved to use the FontCache as the
      source of known fonts

    Cheers
    Andrea

    --
    -----------------------------------------------------
    Ing. Andrea Aime
    Senior Software Engineer

    GeoSolutions S.A.S.
    Via Poggio alle Viti 1187
    55054 Massarosa (LU)
    Italy

    phone: +39 0584962313
    fax: +39 0584962313

    http://www.geo-solutions.it
    http://geo-solutions.blogspot.com/
    http://www.linkedin.com/in/andreaaime
    http://twitter.com/geowolf

    -----------------------------------------------------

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.