On Wed, Aug 5, 2015 at 6:09 PM, Jody Garnett <[email protected]> wrote:
> 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). > This is an API break, but I don't have time to write a proposal. Oh well, I guess I'll leave the deprecations where they are, no time for extra, the feature freeze is close and I also have to work on the z-order thing. > > 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> > Exactly as I said, there is no way to have Arial be italic, but Sans not, font-family is the only one that can hae mutliple > > 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> > This is not part of the spec, which states only font-family can have multiple values.... I see you want to extend it, but I have no scope for it, I'm actually already a few days late. > > 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. > Yep. I'll go for just fixing TextSymbolizerImpl so that it does not eat away the multiple font definitions from SLD 1.0 (thus fixing a regression). Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. -------------------------------------------------------
------------------------------------------------------------------------------
_______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
