Closed egli closed 4 years ago
See http://redmine.sbszh.ch/issues/1414 and sbsdev/dtbook-preptools@9cb348fde843e1f7bd1059cb0889d01568c4cbf4
If we'd change the usage of abbr
we might have to enforce it possibly via some schematron
Well we really have many more options:
"Fix" the xml before sending it to converters other than braille
Fix all other converters
Use the abbr element correctly and use an entity for the space following it
Use the abbr element correctly and no longer collapse spaces between some abbr
s and numbers
isn't such a great solution, 4. will not be accepted by the internal Braille standards group. 3. looks like it could be a workable solution.
As for the entity to choose, we want something that has non-breaking characteristics in the case of large print and collapsing or zero-width in the case of braille. Figure space ( 
) might come pretty close.
Use &csp;
(collapsible/conditional space)
Currently
dtbook:abbr
is used to mark up text that not only happens to be an abbr but also the following white space that is to be dropped for Braille.This is a problem for some of the other converters as the
abbr
element was not meant for white space:abbr
The current practice has been there for a long time and is encouraged by the preptools who seem to include whitespace inside the
abbr
element.I guess we have 3 options:
abbr
element correctly. This would imply