manual/xmlformat/BUGS

   1 xmlformat bugs
   2
   3 Ruby version is slower than the Perl version, a difference that shows up
   4 particularly for larger documents. I haven't done any profiling to determine
   5 which parts of the program account for the differences.
   6
   7 ----------
   8 Within normalized elements, the line-wrapping algorithm preserves inline
   9 tags, but it doesn't take any internal line-breaks within those tags into
  10 account in its line-length calculations.  Consider this element:
  11
  12 <para>
  13 This is text with an inline <inline-element attr="This is
  14 an attribute
  15 value">element</inline-element> in the middle.
  16 </para>
  17
  18 The opening <inline-element> tag is considered to have a length
  19 equal to its total number of characters.  The line-wrapping algorithm
  20 could be made more complex to take the line-breaks into account.
  21 I haven't bothered, and may never bother.  If such a change is made, no
  22 indenting should be applied that would change the attribute value.
  23
  24 ----------
  25 Line-wrapping length calculations don't take into account the possibility
  26 that text from a different element may occur on the same line if break
  27 values are set to zero.  For example, with a wrap-length of 15, you could
  28 end up with output like this:
  29
  30 <listitem><para>This is a line
  31 of text.</para></listitem><listitem><para>This is a line
  32 of text.</para></listitem>
  33
  34 The middle line has more than 15 characters of text.
  35
  36 This also shows that wrap-length doesn't take into account the length of
  37 tags of enclosing blocks on the same line, which can also be considered a
  38 bug.
  39
  40 Fix: Set all your break values > 0.
  41
  42 ----------
  43 Normalization converts runs of spaces to single spaces.  This means that
  44 if you write two spaces after periods in text, normalization will
  45 convert them to single spaces. Even if normalization didn't do that,
  46 the two spaces would be lost if line-wrapping is enabled and they occur
  47 at a line break.
  48
  49 I don't know if this is really a bug, but it's something to be aware of.
  50
  51 ----------
  52 Doesn't recognize multi-byte files. In some cases, you can work around this.
  53 For example, an editor might save a file as Unicode even when the document
  54 contains only ASCII characters.  Re-save the file as an ASCII file (or
  55 some single-byte encoding such as ISO-8859-1) and it should work.