Here is your proposal: https://github.com/geotools/geotools/wiki/Text-Symbolizer-Multi-font-support
I will have a pull request for the API change shortly. Proposal is just for the API change, hooking up the multi-font rendering support is up to you :) -- Jody Garnett On 6 August 2015 at 02:06, Andrea Aime <[email protected]> wrote: > 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
