Hi Susan,
This is a slight change of topic, but one interesting question is the order in
which opening and closing indicators are inserted. I believe in UEB the opening
order is underline, then bold, then italic; and the closing order is reversed.
But the typeform bits are ordered as italic = 1, underline = 2 and bold = 3.
This seems to be a good argument for why these typeforms shouldn't be fixed
numbers like this.
I'm wondering how strictly defined the ordering is. I can imagine the rule of
reversing the closing indicators based on the opening indicators is quite
common, but does UEB also specify that the bold indicator has to precede the
italic indicator? In Dutch there is only one indicator, which preempts the need
for an insertion order but also causes difficulties if you want to distinguish
the various typeforms.
Davy
-----Oorspronkelijk bericht-----
Van: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] Namens Susan Jolly
Verzonden: woensdag 10 februari 2016 17:02
Aan: liblouis-liblouisxml@xxxxxxxxxxxxx
Onderwerp: [liblouis-liblouisxml] Re: Status UEB integration
Hi Bert,
Thanks so much for the explanations. I had read the github entry but had
failed to read all the comments.
I think I understand now what is going on with your suggested approach for
handling emphasis indicators.
When I had to deal with related issues in my translators, which were written in
Java, I took the position that with modern computers it is often easiest make
new versions of an app when new features are added rather than to try to
anticipate possible enhancements so as to avoid the need to update the app. I
used this approach to support extending my trnslators to add additional
translation algorithms such as those needed for proper names in contracted
braille. My implementation requires the user to know the app's internal name
for any new features they wish to use and to specify in their input a mapping
between the app's internal name and the arbitrary external name they've used to
tag items that require the new feature. (Alternatively, the internal name could
be known to a user interface.)
It appears that at least in the case of (most) braille emphasis indicators
there isn't a need for multiple algorithms but only for a single algorithm that
has some way of accessing the appropriate data, i.e. the braille patterns, for
each particular type of emphasis. In this situation of a single algorithm that
uses multiple sets of data, there isn't a need for the app to have a different
hard-coded internal name (symbol) for each set of data. That is, the app can
be implemented to use an arbitrary numerical value, such as a bit flag or array
index, to locate the appropriate data.
This approach means that the user simply has to associate each set of data with
a different number.
I hope I've gotten this right but, if not, I'll be interested in learning more.
Sincerely,
SusanJ
For a description of the software, to download it and links to project pages go
to http://liblouis.org
DISCLAIMER:
De informatie verzonden met dit e-mail bericht is uitsluitend bestemd voor de
geadresseerde. Indien u niet de beoogde geadresseerde bent, verzoeken wij u
vriendelijk dit aan de afzender te melden (of via:
info@xxxxxxxxxx<mailto:info@xxxxxxxxxx>) en het origineel en eventuele kopieën
te verwijderen.
The information sent in this e-mail is solely intended for the individual or
company to whom it is addressed. If you received this message in error, please
notify the sender immediately (or mail to
info@xxxxxxxxxx<mailto:info@xxxxxxxxxx>) and delete the original message and
possible copies.
