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 Georg Datterl <ge...@geneon.de> on 2009/08/24 13:33:51 UTC
Display of fractions
Hi everybody,
In my fo file I have a text like
<fo:inline font-family="arial bold" font-size="4pt" line-height="8pt" baseline-shift="2pt">3</fo:inline>
<fo:inline font-family="arial bold" font-size="6pt" line-height="8pt">∕</fo:inline>
<fo:inline font-family="arial bold" font-size="4pt" line-height="8pt">4</fo:inline>
The second character is Unicode 2215. When I generate the PDF through the batch file from subversion, this sequence looks like 3 / 4, whereas when I generate the PDF through my application, it is pulled together to a bit more than one character width and looks like a true fraction. See attached screenshot. Can anybody tell me, which part of fop is responsible for this difference and why the batch file does not trigger this part? There are no complaints about unfound fonts and the fonts used are identical in both cases.
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
AW: Display of fractions
Posted by Georg Datterl <ge...@geneon.de>.
Hi Andreas,
You are right. Both pdfs are created from the same fo file, but the one which doesn't work as expected is reformatted by Xmlspy first. And there's no way as far as I can see, to keep the inlines in one line. Well, doesn't matter. I was hoping it would be a clue to improve the blank-block algorithm, but no luck. Thanks for your help, now I can concentrate on the next problem.
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Andreas Delmelle [mailto:andreas.delmelle@telenet.be]
Gesendet: Montag, 24. August 2009 18:13
An: fop-users@xmlgraphics.apache.org
Betreff: Re: Display of fractions
On 24 Aug 2009, at 13:33, Georg Datterl wrote:
Hi Georg
> In my fo file I have a text like
> <fo:inline font-family="arial bold" font-size="4pt" line- height="8pt"
> baseline-shift="2pt">3</fo:inline>
> <fo:inline font-family="arial bold" font-size="6pt" line-
> height="8pt">∕</fo:inline> <fo:inline font-family="arial bold"
> font-size="4pt" line- height="8pt">4</fo:inline>
>
> The second character is Unicode 2215. When I generate the PDF through
> the batch file from subversion, this sequence looks like 3 / 4,
> whereas when I generate the PDF through my application, it is pulled
> together to a bit more than one character width and looks like a true
> fraction. See attached screenshot. Can anybody tell me, which part of
> fop is responsible for this difference and why the batch file does not
> trigger this part?
My best guess would be a difference in white-space in the source FO.
If you serialize it to disk first, depending on the value of the 'indent' attribute on xsl:output, the XSLT processor may add white- space in between the fo:inlines. When you feed XML+XSLT to FOP in your application, the fo:inlines are most likely not separated by white- space (a compliant XSLT processor should ignore the 'indent' attribute in that case), hence why you get the intended result there.
Note that there is, AFAIK, no combination of related properties in XSL- FO that would completely suppress the linefeeds between the fo:inlines. There will always at least remain a space, which could be a ZWSP if linefeed-treatment is set to "treat-as-zero-width-space".
The only fail-safe approach is always to make sure that there is no white-space in the FO source that you do not intend to see in the eventual output.
HTH!
Andreas
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandreas@jabber.org
skype: adlm0608
---
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Display of fractions
Posted by Andreas Delmelle <an...@telenet.be>.
On 24 Aug 2009, at 13:33, Georg Datterl wrote:
Hi Georg
> In my fo file I have a text like
> <fo:inline font-family="arial bold" font-size="4pt" line-
> height="8pt" baseline-shift="2pt">3</fo:inline>
> <fo:inline font-family="arial bold" font-size="6pt" line-
> height="8pt">∕</fo:inline>
> <fo:inline font-family="arial bold" font-size="4pt" line-
> height="8pt">4</fo:inline>
>
> The second character is Unicode 2215. When I generate the PDF
> through the batch file from subversion, this sequence looks like 3 /
> 4, whereas when I generate the PDF through my application, it is
> pulled together to a bit more than one character width and looks
> like a true fraction. See attached screenshot. Can anybody tell me,
> which part of fop is responsible for this difference and why the
> batch file does not trigger this part?
My best guess would be a difference in white-space in the source FO.
If you serialize it to disk first, depending on the value of the
'indent' attribute on xsl:output, the XSLT processor may add white-
space in between the fo:inlines. When you feed XML+XSLT to FOP in your
application, the fo:inlines are most likely not separated by white-
space (a compliant XSLT processor should ignore the 'indent' attribute
in that case), hence why you get the intended result there.
Note that there is, AFAIK, no combination of related properties in XSL-
FO that would completely suppress the linefeeds between the
fo:inlines. There will always at least remain a space, which could be
a ZWSP if linefeed-treatment is set to "treat-as-zero-width-space".
The only fail-safe approach is always to make sure that there is no
white-space in the FO source that you do not intend to see in the
eventual output.
HTH!
Andreas
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandreas@jabber.org
skype: adlm0608
---
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org