[liblouis-liblouisxml] Guaranteeing Braille content on a separate line in UTD
- From: "Michael Whapples" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "mwhapples@xxxxxxx" for DMARC)
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Tue, 08 Jul 2014 10:39:29 +0100
Hello,
In adding box lines for sidebars I hit a bit of UTD I am not sure
whether it is defined. So I thought it might be worth discussing the
idea here to see whether others have a view on how this should be done.
My difficulty is that when LibLouisUTDML needs to generate a line of
Braille content which must be guaranteed to be on a separate line (eg. a
box line for a sidebar) how should the UTD mark up be done to ensure
this guarantee is met?
I get a difficulty surrounding the newline node in UTD, it does not seem
fully defined what precisely it is and where it should appear. It
obviously is some sort of line break marker, however I get the feeling
due to the xy attribute it may be intended to lead the content rather
than follow the content, which is the opposite of line break characters
in a text file (IE. UTD might require a newline node before any Braille
content, where as in a text file one does not start with a new line
character). However what I have just said is what I have gathered, due
to no clear documentation of its meaning I may have it wrong.
Anyway back to the actual problem of guaranteeing Braille content on a
separate line.
My initial implementation of boxlines for sidebars ends up with UTD
content like:
<sidebar ...>
<brl>7777777777777777777777777777777777777777</brl>
...<brl index="...">...</brl>
<brl>gggggggggggggggggggggggggggggggggggggggg</brl>
</sidebar>
This above UTD mark up is not acceptable as the guarantee is not
ensured, it relies on UTD markup around it providing the new lines, thus
the boxline brl node itself has no guarantees on placement.
The first option which occurs to me is to place a newline node at the
beginning and end of the brl boxline node:
<brl><newline xy="...">7777777777777777777777777777777777777777<newline
xy="..."/></brl>
My concern is that by placing a newline node at the beginning and end of
the boxline brl nodes could lead to additional blank lines which are not
desired (IE. my concern being that liblouisutdml will advance the y
coordinate more than it should).
There is part of me feeling that newline nodes do not fit with the XML
spirit of doing things, it might be better to have a line node with the
content of the node being the line:
<brl><line x="..."
y="...">7777777777777777777777777777777777777777</line></brl>
However that would be major work to software using UTD, so I could
imagine it not being popular.
So would it be worth having a marker to indicate end of line (IE. no
more content for this line). My thought here being that if no newline
node appears after such a marker (IE. more brl content immediately
follows) then the software using the UTD should place the content on a
new line, advancing a line vertically and using the default margin. If a
newline node immediately follows then the xy attribute will be used for
placement. In practice this means newline nodes mostly could be inferred
from these line end markers as they are only needed when a position must
be explicitly given for the start of the next line.
For clarity in that last paragraph when I say "immediately follows", I
do not necessarily mean it immediately follows in the XML, it may be in
a different brl node, but it is the next piece of content in the Braille.
What are peoples' thoughts on these options? Have I missed a way of
doing what I want to with the existing UTD mark up?
Michael Whapples
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
