Re: xfc_pro_java fo2docx and fo2odt render list-item with leading minus sign incorrectly

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