mirror of
https://github.com/Ardour/ardour.git
synced 2026-01-10 15:36:24 +01:00
9d548f998b
and consistant aswell as a configuration file. When I converted the manual to docbook I was using an old version that I'd modified to insert tabs rather than spaces so using it on the existing documentation will appear to reformat the whole file. I don't think that matters at this stage and I'm tempted to reformat everything now while it isn't an issue. Rewrote the Makefile that builds the docs so that: - building the html only depends on having xsltproc installed. - the xsl and xml files aren't copied to the build directory. - make test does not remove an existing build of the docs. Changed the glossary so that the acronym/abbreviations are the glossary terms, which I've discovered is how it is generally done. It makes total sense now that I actually think about it because you need to find the terms based on their use in the manual. Added a bit of xsl to add the status attribute as a class attribute in the html so that the css can use a draft watermark(or any other watermark). DocBook supports the draft status without the xsl but it has problems, which I've described in the xsl file. Minor tweak to the css to make the glossary terms and any other definition lists bold(that includes the index). git-svn-id: svn://localhost/ardour2/trunk@1457 d708f5d6-7413-0410-9779-e7cbd77b26cf
55 lines
2.2 KiB
Text
55 lines
2.2 KiB
Text
xmlformat bugs
|
|
|
|
Ruby version is slower than the Perl version, a difference that shows up
|
|
particularly for larger documents. I haven't done any profiling to determine
|
|
which parts of the program account for the differences.
|
|
|
|
----------
|
|
Within normalized elements, the line-wrapping algorithm preserves inline
|
|
tags, but it doesn't take any internal line-breaks within those tags into
|
|
account in its line-length calculations. Consider this element:
|
|
|
|
<para>
|
|
This is text with an inline <inline-element attr="This is
|
|
an attribute
|
|
value">element</inline-element> in the middle.
|
|
</para>
|
|
|
|
The opening <inline-element> tag is considered to have a length
|
|
equal to its total number of characters. The line-wrapping algorithm
|
|
could be made more complex to take the line-breaks into account.
|
|
I haven't bothered, and may never bother. If such a change is made, no
|
|
indenting should be applied that would change the attribute value.
|
|
|
|
----------
|
|
Line-wrapping length calculations don't take into account the possibility
|
|
that text from a different element may occur on the same line if break
|
|
values are set to zero. For example, with a wrap-length of 15, you could
|
|
end up with output like this:
|
|
|
|
<listitem><para>This is a line
|
|
of text.</para></listitem><listitem><para>This is a line
|
|
of text.</para></listitem>
|
|
|
|
The middle line has more than 15 characters of text.
|
|
|
|
This also shows that wrap-length doesn't take into account the length of
|
|
tags of enclosing blocks on the same line, which can also be considered a
|
|
bug.
|
|
|
|
Fix: Set all your break values > 0.
|
|
|
|
----------
|
|
Normalization converts runs of spaces to single spaces. This means that
|
|
if you write two spaces after periods in text, normalization will
|
|
convert them to single spaces. Even if normalization didn't do that,
|
|
the two spaces would be lost if line-wrapping is enabled and they occur
|
|
at a line break.
|
|
|
|
I don't know if this is really a bug, but it's something to be aware of.
|
|
|
|
----------
|
|
Doesn't recognize multi-byte files. In some cases, you can work around this.
|
|
For example, an editor might save a file as Unicode even when the document
|
|
contains only ASCII characters. Re-save the file as an ASCII file (or
|
|
some single-byte encoding such as ISO-8859-1) and it should work.
|