You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Graeme Kidd <co...@hotmail.com> on 2011/02/03 20:38:27 UTC
Font detection on a Character by Character basis
Hi,
Just noticed that FOP detects what font is needed based on the first letter of the word. For example if the sequence of letters was used "N⇒Y" then FOP would by default use the Helvetica font resulting in "N#Y". If I wanted it to display correctly I would need to place an inline element round the ⇒ symbol specifying the Symbol font family.
The only problem is that I can’t easily place an inline element round characters since XALAN only supports XSLT 1.0 and character maps are only available in version 2.0.
Unless if anyone has any better ideas for how I could place inline elements round particular characters I was wondering if any one knows how much of a performance hit FOP would take if a character by character analysis for font detection was used. Also if it was something easy I might try patching it myself.
Thanks,
Graeme
Re: Font detection on a Character by Character basis
Posted by Andreas Delmelle <an...@telenet.be>.
On 03 Feb 2011, at 20:38, Graeme Kidd wrote:
> Just noticed that FOP detects what font is needed based on the first letter of the word.
<snip />
BTW, note that this is not entirely correct. FOP selects the font that can render most of the characters. If you were to make it "N⇒⇒⇒Y", you would see "#⇒⇒⇒#"
Regards,
Andreas
---
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Font detection on a Character by Character basis
Posted by Andreas Delmelle <an...@telenet.be>.
On 03 Feb 2011, at 21:26, Graeme Kidd wrote:
Hi Graeme
>
> If adapting FOP to detect Fonts on a character by character basis is not advisable then I will look into your suggestion of recursive templates on the text() nodes or if that slows things down too far I will just have to move onto SAXON.
On the one hand, it should prove relatively straightforward to adapt FOP to switch to generating separate boxes for each character in a given font, depending on the value of the font-selection-strategy property. The property is already parsed and bound to the FOs, so all that really needs to be changed is org.apache.fop.layoutmgr.inline.TextLayoutManager, mainly getNextKnuthElements(). It seems conceivable to check if the current character can be rendered in the same font as the previous one, and if not, terminate the word-fragment and start a new one. We would then end up with three consecutive boxes in the example, whereas currently, we only generate one.
On the other hand, there is currently still an issue that may prove harder to solve, even with the word-by-word selection. The issue is the alignment of the glyphs in the different fonts. You can check this for yourself if, instead of using fo:inline, you would insert word-joiners (U+2060) in between the characters. That will force FOP to treat each character as its own 'word', and select the correct font for each.
You will then notice that the Symbol glyph appears much too low in comparison to the Helvetica glyphs. This issue is mitigated if you use fo:inlines, since those establish their own alignment-context.
Regards,
Andreas
---
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Font detection on a Character by Character basis
Posted by Graeme Kidd <co...@hotmail.com>.
Thanks Chris, I should have mentioned that I am trying to avoid SAXON at the moment because I need to make use of Java Extensions which are only available on the Professional edition which costs £50 per machine.
If adapting FOP to detect Fonts on a character by character basis is not advisable then I will look into your suggestion of recursive templates on the text() nodes or if that slows things down too far I will just have to move onto SAXON.
Graeme
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/03/2011 02:38 PM, Graeme Kidd wrote:
> > The only problem is that I can’t easily place an inline element round
> > characters since XALAN only supports XSLT 1.0 and character maps are
> > only available in version 2.0.
>
> This can be done in XSLT 1.0 using recursive templates on the text()
> nodes. I have done it, but it slows processing down considerably.
> (Follow-ups on that are best sent to xsl-list, as they are not FOP
> specific.)
>
> Do keep in mind, though, that FOP can be used as part of a two-stage
> process; you could use Saxon to convert your XML to FO, then run FOP on
> the FO. You probably could even specify Saxon as the transformer in
> preference to Xalan, but I haven’t tried that lately.
>
> ~Chris
> - --
> Chris Maden, text nerd
> “For a successful technology, reality must take precedence over
> public relations, for Nature cannot be fooled.” — R.P. Feynman
> GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1LCYkACgkQGfhmdwB3wxlb6gCghZ40tJduqJtnuPCJ86/jFEP0
> RLkAn2cDZ7LgGH5I2MwrGZ+vgOlogKKX
> =Yi8g
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Font detection on a Character by Character basis
Posted by "Christopher R. Maden" <cr...@maden.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/03/2011 02:38 PM, Graeme Kidd wrote:
> The only problem is that I can’t easily place an inline element round
> characters since XALAN only supports XSLT 1.0 and character maps are
> only available in version 2.0.
This can be done in XSLT 1.0 using recursive templates on the text()
nodes. I have done it, but it slows processing down considerably.
(Follow-ups on that are best sent to xsl-list, as they are not FOP
specific.)
Do keep in mind, though, that FOP can be used as part of a two-stage
process; you could use Saxon to convert your XML to FO, then run FOP on
the FO. You probably could even specify Saxon as the transformer in
preference to Xalan, but I haven’t tried that lately.
~Chris
- --
Chris Maden, text nerd <URL: http://crism.maden.org/ >
“For a successful technology, reality must take precedence over
public relations, for Nature cannot be fooled.” — R.P. Feynman
GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1LCYkACgkQGfhmdwB3wxlb6gCghZ40tJduqJtnuPCJ86/jFEP0
RLkAn2cDZ7LgGH5I2MwrGZ+vgOlogKKX
=Yi8g
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org