In order to answer your question about "how users are supposed to indicate
that for a particular translation the chosen user-defined typeform
indicator, such as trans1, is to be used for indicating crossed out text",
I should add some more explanation:
The idea is that applications that use Liblouis will provide a way for
their users to make such configurations. The reason for this is simple
because configuration is part of the user interface and every application
has its own configuration mechanism.
For example in DAISY Pipeline the approach would be to use CSS:
s {
text-transform: ueb-trans1;
}
2016-02-10 11:04 GMT+01:00 Bert Frees <bertfrees@xxxxxxxxx>:
Hi Susan,
Thanks for asking, because this is an important part of the new strategy.
I have tried to explain it in the github issue, mainly in this comment:
https://github.com/liblouis/liblouis/issues/99#issuecomment-114063564.
Have you read this too?
I think there's a shift that needs to happen in the way that applications
use Liblouis, although we remain backwards compatible for the time being.
In the future Liblouis tables will be able to define any mapping between
"typeform classes" and braille indicators. How these classes are named and
what they mean is completely up to the individual translation tables.
Classes can have the meaning of "print artifacts", as I've called them in
the github comment, i.e. properties of the font, or HTML tags (e.g. italic,
bold, etc.). But classes can also simply have the meaning of indicator
names (e.g. ueb-trans1, ueb-trans2, etc.).
The key point to understand here is that the class names and meanings are
part of the translation table interface and applications have to be aware
of them. (Changes to the interface will be properly announced in the
changelog etc.)
I think this freedom in defining typeform classes is essential for the
expressiveness of Liblouis tables. But on the other hand all this freedom
doesn't make life easier for the applications that use liblouis. The idea
is that there will be some standard class names with a standard meaning, in
order to provide some structure for generic applications, while more
specialized applications can use the full set of classes defined in a table.
The first 3 standard typeform classes are the ones that existed already in
liblouis: italic, bold and underline. Gradually more and more classes can
be standardized. There will be a function that applications can use to
dynamically get the position of the bit in the typeform argument that
corresponds with a certain class name.
Important to realize however is that we can never get to a point where
applications can blindly pass on all styling information to Liblouis and
expect that the right braille will come out. Firstly because we can never
capture all possible styling possibilities with our set of standardized
classes. And secondly because the mapping from style to braille indicator
can be context dependent and may require human intervention while the
context that liblouis gets is typically only a single paragraph.
2016-02-10 0:55 GMT+01:00 Susan Jolly <easjolly@xxxxxxxxxxxxx>:
Hi John,
Thanks for the reply. However, I'm still not sure how liblouis is always
able to match up the terminology in a translation table with the
terminology provided by liblouisutdml. For example, HTML5 uses its "s" tag
to indicate contents that are no longer accurate. Typically this is
rendered by struck-through text which is text that is still readable but
where the letters have a horizontal line printed across the middle.
If a sighted user transcribing a document to UEB views the rendered
source, they will note that some of the text has been what is referred to
as "crossed out" in the UEB Rulebook and will thus need to emply a
user-defined typeform indicator. However, I don't know how the user is
supposed to indicate that for this particular translation the chosen
user-defined typeform indicator, such as trans1, is to be used for
indicating "crossed out" text. I also don't understand how liblouis would
match up the user's "crossed out" terminology with an "s" tag.
SusanJ
