#114 hyphen-encode can sometimes drop meaningful spaces

[Raphael Hertzog]

When you use a tag that is processed by inline.monoseq or inline.sansseq and whose content is thus handled by hyphen-encode, the resulting PDF will (sometimes) drop a meaningful space.

In the Debian Handbook I have <literal>Architecture: all</literal> and in the PDF, the space is gone. In the .tex file, the space is still here but after a :\penalty0 and I guess that the two consecutive spaces are collated at this point and that it would need to be escaped in some way to be kept as a meaningful space.

(Note that I have custom XSL so that the literal tag is processed by inline.sansseq, it's not that way by default)

[Raphael Hertzog]

Hum, so this means that my tag is processed by the UrlHyphenator class. I have an easy fix in dbtexmf/dblatex/texhyphen.py, just replace h_sep and h_char like this:

    def __init__(self, codec=None,
                 h_sep="\penalty0{}", h_char="\penalty5000{}",
                 h_start=3, h_stop=3):

This seems to work for me without any side-effect so far.

[Raphael Hertzog]

The full patch for clarity:

--- a/lib/dbtexmf/dblatex/texhyphen.py
+++ b/lib/dbtexmf/dblatex/texhyphen.py
@@ -49,7 +49,7 @@ class UrlHyphenator(Hyphenator):
     existing latex styles.
     """
     def __init__(self, codec=None,
-                 h_sep="\penalty0 ", h_char="\penalty5000 ",
+                 h_sep="\penalty0{}", h_char="\penalty5000{}",
                  h_start=3, h_stop=3):
         self.codec = codec
         self.seps = r":/\@=?#;-."

[Raphael Hertzog]

This bug is also tracked on the Debian bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862332

It contains a minimal test case here:
XML: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=862332;filename=test.xml;msg=15
PDF: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=862332;filename=test.pdf;msg=15

It would be nice to get this bug fixed in an official dblatex release.

[Guillon]

Thanks for reporting this bug. The patch works for one space, but if there are other following spaces they are not preserved. Moreover the space rendering with a normal space is not the one expected in literal mode. So the patch I propose is the following:

--- a/xsl/inlined.xsl   Tue Apr 04 00:58:42 2017 +0200
+++ b/xsl/inlined.xsl   Tue May 16 19:58:24 2017 +0200
@@ -28,7 +28,14 @@
   <xsl:choose>
   <xsl:when test="contains($hyphenation.format, $format)">
     <xsl:call-template name="hyphen-encode">
-      <xsl:with-param name="string" select="$string"/>
+      <!-- Use control space '\ ' to show all spaces in literal mode --> 
+      <xsl:with-param name="string">
+        <xsl:call-template name="scape-replace" >
+          <xsl:with-param name="string" select="$string"/>
+          <xsl:with-param name="from" select="' '"/>
+          <xsl:with-param name="to" select="'\ '"/>
+        </xsl:call-template>
+      </xsl:with-param>
     </xsl:call-template>
   </xsl:when>
   <xsl:otherwise>

I attach a test case showing the need to preserve all the spaces, and the patch.

[Guillon]

Attached the test case showing with an example the need to preserve spaces.

[Raphael Hertzog]

I'm not sure that this is correct. Neither code nor literal are verbatim elements according to the Docbook specification (they are both "inline"). So multiple spaces are not necessarily intended. Also consider what line wrapping might have as consequences with your change:

<para>
     Consider the value <literal>one 
     two</literal>... how many spaces
     should it contain?
</para>

[Guillon]

Yes, you're right! I've reverted the XSL file and applied your patch. I guess Andreas can package a debian release with this.

[Guillon]

Fixed in 0.3.11 release.

[Guillon]

Fixed in 0.3.11 release.