Hi Alexey, When I use the default fonts in FOP and remove the special code and allow FOP 1.1 to fall back through the font list to Symbol, then the arrow character is positioned slightly *below* the baseline, which looks awful. If I retain the fo:inline font-family="Symbol", then it positions correctly. So I will retain the fo:inline exception and set it to the $symbol.font.family (if it is not blank), until the FOP folks can implement this feature correctly.
You don't seem to have this problem because your body font contains the symbol and does not have to switch fonts, apparently. Bob Stayton Sagehill Enterprises b...@sagehill.net From: Bob Stayton Sent: Friday, May 10, 2013 11:30 PM To: Alexey Neyman ; docbook-apps@lists.oasis-open.org Subject: Re: <menuchoice> FOP quirk Hi Alexey, That arrow symbol is not in the default fonts used by FOP, so it had to be found in the most likely place, the Symbol font. Normally the FO property font-selection-strategy="character-by-character" would have worked to fall back from the body font to the Symbol font to get the character. However, in 2007, when that code was introduced, FOP did not support font-selection-strategy="character-by-character" (see http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy). So at that time it was a necessary fix to switch to the Symbol font for that character. I agree that it should not have hard wired the Symbol font name, and should have used the $symbol.font.family if it existed. But I believe the code is now obsolete because that property is now supported in FOP. I'll clean up the template in inline.xsl. BTW, if you have $symbol.font.family set to blank, one of the fonts in your set must be supplying that character. The default fop fonts don't supply it (I get # instead). Bob Stayton Sagehill Enterprises b...@sagehill.net From: Alexey Neyman Sent: Friday, May 10, 2013 4:23 PM To: docbook-apps@lists.oasis-open.org ; Bob Stayton Subject: <menuchoice> FOP quirk Hi all, and especially Bob (since you introduced the code below), I am seeing a weird formatting artifact with FOP, where the arrow introduced between the parts of <menuchoice> sequence results in an increase of line height. It is especially visible where that line is a part of list item, as the list marker ends up being near the top of the line rather than in a middle. A screenshot is attached, and another one shows (with thin colored boxes) the height of the elements inside a <menuchoice>) I traced this to the the following XSL code in fo/inline.xsl: <xsl:variable name="mm.separator"> <xsl:choose> <xsl:when test="($fop.extensions != 0 or $fop1.extensions != 0 ) and contains($menuchoice.menu.separator, '→')"> <fo:inline font-family="Symbol"> <xsl:copy-of select="$menuchoice.menu.separator"/> </fo:inline> </xsl:when> <xsl:otherwise> <xsl:copy-of select="$menuchoice.menu.separator"/> </xsl:otherwise> </xsl:choose> </xsl:variable> If I remove that fo:inline, <menuchoice> is formatted correctly. We don't use Symbol font, and we don't have it in fop.cfg. For that reason, we have $symbol.font.family set to empty value in our customization. Yet, this template bypasses the $symbol.font.family and attempts to use Symbol font directly. It maybe a font issue (having a glyph which exceeds the font size?), but the core issue is why DocBook XSL is attempting to use a font it wasn't configured to use? I tried to dig the history what this workaround was trying to solve, but the commit message is not very descriptive: Author: bobstayton Date: Fri Apr 22 07:27:58 2005 UTC (8 years ago) Changed paths: 1 Log Message: Fix menuchoice.menu.separator for FOP. Can you shed some light as to what issue this code tries to fix? Removing this <xsl:choice> and using $menuchoice.menu.separator seems to work fine for me (using FOP 1.1). If it is kept, is it possible to: add "and $symbol.font.family != ''" to <xsl:when/>, and set font-family to "{$symbol.font.family}"? Regards, Alexey. If removal
