https://issues.apache.org/bugzilla/show_bug.cgi?id=50865
--- Comment #2 from Glenn Adams <gl...@skynav.com> 2011-03-03 15:27:44 EST --- I believe this is an interpretation (and thus implementation) error, rather than a spec error. Every #PCDATA character in FO is modeled as an anonymous, individual fo:character, whether explicitly wrapped in fo:character or not (see 1.1.2): "As part of the step of objectifying, the characters that occur in the result tree are replaced by fo:character nodes." Since the "language" property applies to fo:character (along with the other common hyphenation properties), and since it is inherited, then during property refinement, the appearance of the language property on an ancestor, e.g., fo:wrapper, fo:inline, etc., applies for the purpose of determining the language of these anonymous fo:character FOs. So, in fact, "ignoring fo:character" is the fundamental error here. You can't ignore fo:character for hyphenation properties that might be specified on inline, wrapper, etc. G. (In reply to comment #1) > The problem is most likely caused by the FO specification, which makes > hyphenation > properties, including the language relevant for hyphenation, only effective on > fo:block, which corresponds to DocBook paragraph level elements (ignoring > fo:character here). The ForeignPhrase DocBook element appears to be an inline > element, therefore changing the language here is ignored. You can check for > yourself by generating and examining the FO output for your DocBook source. > For further reference, see http://www.w3.org/TR/xsl/ > > I'll leave this report open because honoring the language on fo:inline, > fo:wrapper and perhaps other inline flow elements would make an useful > extension. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
