Hi Hussein Did you guys ever fix this bug?
I just got bitten by it again, i.e.,: Enumerated Values: 1 3 got turned into Enumerated Values: 1 2 and the only way I could fix it was by swapping the order to: Enumerated Values: 3 1 since inserting a space before the numbers didn't work this time. It would be nice if there was a way to turn off your too clever for its own good auto-detection with a command line parameter, since messing with the FO output of the DocBook stylesheets to insert a processing instruction as you suggest is way too complicated for a simple soul like me. David On 7/9/15 12:45 PM, Hussein Shafie wrote: > On 07/09/2015 06:12 PM, David Clunie wrote: >> >> I came across an issue where a '-1' in a DocBook <variablelist/> >> <varlistentry/> <term/> that is rendered in the FO as a >> <fo:list-block/> <fo:list-item/> <fo:block/> <fo:inline/> text >> value is being rendered in the DOCX or ODT as '2', not '-1'. >> >> The Word output looks like: >> >> Enumerated Values: >> 1 Lower pixel values correspond to less X-Ray beam intensity >> 2 Higher pixel values correspond to less X-Ray beam intensity >> >> whereas it should be: >> >> Enumerated Values: >> 1 Lower pixel values correspond to less X-Ray beam intensity >> -1 Higher pixel values correspond to less X-Ray beam intensity >> >> and I notice that it is using the Word bullet numbering feature for >> these, which is perhaps (incorrectly) automatically detected in this >> case. >> >> I have attached an FO object that demonstrates the problem (towards >> the end of the file): >> >> <fo:block xmlns:d="http://docbook.org/ns/docbook"; >> xmlns:rx="http://www.renderx.com/XSL/Extensions"; >> space-before.optimum="1em" space-before.minimum="0.8em" >> space-before.maximum="1.2em" >> keep-with-next.within-column="always">Enumerated Values:</fo:block> >> <fo:list-block id="idp140441762944656" >> provisional-distance-between-starts="2em * 0.60+1em" >> provisional-label-separation="1em" space-before.optimum="0.5em" >> space-before.minimum="0.4em" space-before.maximum="0.6em" >> space-after.optimum="0.5em" space-after.minimum="0.4em" >> space-after.maximum="0.6em"> >> <fo:list-item id="idp140441762961952" >> space-before.optimum="0em" space-before.minimum="0em" >> space-before.maximum="0.2em"> >> <fo:list-item-label end-indent="label-end()" >> text-align="start"> >> <fo:block hyphenate="false" font-weight="bold"> >> <fo:inline>1</fo:inline> >> </fo:block> >> </fo:list-item-label> >> <fo:list-item-body start-indent="body-start()"> >> <fo:block> >> <fo:block >> id="para_53931309-ab74-4e67-8066-e7b0b19b66d5">Lower pixel values >> correspond to less X-Ray beam intensity</fo:block> >> </fo:block> >> </fo:list-item-body> >> </fo:list-item> >> <fo:list-item id="idp140441763193200" >> space-before.optimum="0em" space-before.minimum="0em" >> space-before.maximum="0.2em"> >> <fo:list-item-label end-indent="label-end()" >> text-align="start"> >> <fo:block hyphenate="false" font-weight="bold"> >> <fo:inline>-1</fo:inline> >> </fo:block> >> </fo:list-item-label> >> <fo:list-item-body start-indent="body-start()"> >> <fo:block> >> <fo:block >> id="para_44931a0f-f13b-4d9a-97ea-fe0e2884cf1a">Higher pixel values >> correspond to less X-Ray beam intensity</fo:block> >> </fo:block> >> </fo:list-item-body> >> </fo:list-item> >> </fo:list-block> >> >> and >> >> I assume this is a consequence of what is described in the documentation >> (section 4.2 "XFC automatically tries to infer the numbering style from >> the label of the first list item") > > Yes, that's right. > > > >> >> If I put a space before the minus sign in the second list item, it >> renders >> as expected (as ' -1'), in case that helps diagnose the problem, but then >> that creates an unwanted space in the output. >> > > I'm sorry but there is currently no other workaround than the one you > have found. > > A possible solution to this problem would be to invent a new > processing-instruction (<?xfc-label-format?>) that you would insert > inside the above DocBook <variablelist/>. > > This processing-instruction would instruct XFC not to infer a numbering > style, which is currently possible, but only at the XSL-FO level. See > http://www.xmlmind.com/foconverter/_distrib/doc/user/implementation.html#xfc_label-format > > > > > -- XMLmind FO Converter Support List [email protected] http://www.xmlmind.com/mailman/listinfo/xfc-support
