Quick +1 for restoring the functionality. Additional comments inline ...
The methods in questions are in this interface: > > https://github.com/geotools/geotools/blob/master/modules/library/api/src/main/java/org/geotools/styling/TextSymbolizer.java#L321 > This is our GeoTools "shadow" read/write interface - so it is fairly easy to use for extra/non-standard/vendor options :) I would like to recommend the following: /** * Returns a device independent Font object that is to be used to render * the label. * * @deprecated use getFont() */ Font[] getFonts(); /** Direct access to list of fonts used to render the label */ List<Font> fonts(); This approach is more consistent with our rewrite to make the geotools style interfaces direct access collections (rather than array based). Why this was a mistake: > * SLD 1.0 is still supported, and so we should avoid throwing away the > extra fonts that can be declared > as fallbacks like the current TextSymbolizerImpl does (in order to align > with that deprecation) > * SLD 1.0 is for once more expressive than SE 1.1, so deprecating those > methods is a functional regression. > Yeah I am a bit werided out by that ... your explanation is sound. Here is the example from the OGC docs: <Font> <SvgParameter name="font-family">Arial</SvgParameter> <SvgParameter name="font-family">Sans-Serif</SvgParameter> <SvgParameter name="font-style">italic</SvgParameter> <SvgParameter name="font-size">10</SvgParameter> </Font> The second statement warrants an explanation. In SE 1.1 a Font can have > multiple font families, > but can still have only one of the other attributes, so all font families > are cast to use the same > size... which is pretty ridiculous, I believe that everybody ever using a > word processor noticed > how monospaced fonts tend to be bigger than non monospaced ones, don't > know about you, > but I normally bring monospaced fonts size down 1 or 2 points to > compensate. > Is it worth considering the following: <Font> <SvgParameter name="font-family">Arial Black</SvgParameter> <SvgParameter name="font-family">Arial</SvgParameter> <SvgParameter name="font-family">Sans-Serif</SvgParameter> <SvgParameter name="font-style">normal</SvgParameter> <SvgParameter name="font-style">bold</SvgParameter> <SvgParameter name="font-style">bold</SvgParameter> <SvgParameter name="font-size">10</SvgParameter> <SvgParameter name="font-size">11</SvgParameter> <!--SvgParameter name="font-size">11</SvgParameter--> </Font> I have commented out the last font-size setting to show carrying forward the last "setting" when defining the list of fonts. We can still parse this into our Font[] internally. > As a possible alternative, we could downgrade SLD 1.0 flexibility to SE > 1.1 one, keep the > deprecations, but TextSymbolizerImpl would still have to be modified not > to eat away > the extra fonts like it does today (SLDParser sets n fonts, TextSymbolizer > retains only > the first). > See above for idea on encoding a list of fonts in SE 1.1. > CSS wise, there is not support for multiple fonts right now (not even for > the family), > not sure if I'll managed to work on that too, but it's unrelated (the > limitation was > already there) and the module is unsupported anyways. > Got it, if you don't have scope for SE 1.1 representation I would like to table the approach for later. Jody
------------------------------------------------------------------------------
_______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
