xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Date Tue, 02 Dec 2008 13:28:56 GMT
On 02.12.2008 13:51:06 Chris Bowditch wrote:
> Jeremias Maerki wrote:
> 
> > Hi Vincent,
> > 
> > these alternatives are only taken as a last resort before mentioning
> > that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
> > MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
> > Otherwise, I wouldn't have made the change. The change is also not about
> > replacing minus for a hyphen, but for the other way around. I can of
> > course add a warning if an alternative glyph is used. But I guess some
> > people would find the warning welcome while others might find it a
> > nuisance. Can we get some additional opinions to reach an informed
> > decision, please?
> 
> Thanks for the explanation. I was also thinking about this yesterday 
> afternoon. I don't like the idea of the warning, because that makes 
> users think there is something wrong when in fact there isn't but maybe 
> an info level event instead to help make the process more transparent.
> 
> Does this glyph relationship apply to XSL-FO and SVG Text or just SVG 
> text?

It's the same for both XSL-FO and SVG as long as FOP's font library is
involved, i.e. for PDF, PS, AFP. But if for those formats stroked text
is used or if you're generating Java2D, TIFF/PNG or PCL, the SVG
production is completely in the hands of Batik. The behaviour can be
different. And Batik still doesn't use XML Graphics Commons.

> I think making the whole SVG Text process more transparent would 
> really help as it seems quite mystical. I know you made some further 
> notes on this process yesterday, but some more details about Font 
> substitution and glyph relations would be useful.

That stuff is not mystical, just complicated because by now we have so
much functionality and support so many different output formats which
all have slightly different facilities. Furthermore, when I refactored
the SVG/PDF text painting I didn't have enough time to improve Batik's
font support so we it would be possible to plug FOP's font support into
Batik. Add to that the fact that, for example, PostScript and AFP still
have inferior text handling for SVG graphics which causes a higher
percentage of SVG text to be painted as shapes.

I'm not sure how to make the documentation much clearer. Font
substitution itself is well documented. I'm hesitant to go in the
details of glyph relations because the best approach would be to
document all the substitutions we make and if that data is not generated
from the same source as the functionality in the code we always risk
losing synchronization. And that's a lot of work for little gain.

> BTW, XEP does the same glyph substitution, so I guessed there must be 
> some standard dictating this behaviour.
> 
> Regards,
> 
> Chris
> 
> > 
> > On 02.12.2008 12:22:29 Vincent Hennebert wrote:
> > 
> >>Hi Jeremias,
> >>
> >>
> >>>Author: jeremias
> >>>Date: Mon Dec  1 08:00:50 2008
> >>>New Revision: 722108
> >>>
> >>>URL: http://svn.apache.org/viewvc?rev=722108&view=rev
> >>>Log:
> >>>Added "minus" as an alternative for "hyphen" & Co.
> >>
> >>Why? minus has nothing to do with hyphen, and the result is likely to
> >>look terrible. I think I would prefer to have a warning rather than
> >>a silent replacement. Anyway, if a font doesn’t even define a glyph for
> >>hyphen, then I doubt it will define one for the true minus.
> >>
> >><snip/>
> >>
> >>Vincent
> > 
> > 
> > 



Jeremias Maerki


---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org


Mime
View raw message