[liblouis-liblouisxml] Re: Issue with emphasis

  • From: "Michael Whapples" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "mwhapples@xxxxxxx" for DMARC)
  • To: liblouis-liblouisxml@xxxxxxxxxxxxx
  • Date: Wed, 19 Nov 2014 23:34:01 +0000

Hello,
I follow the logic and agree that ideally it might be best fixed in liblouis.

However there may be issues with that, not necessarily things which prevent it but things we may wish to consider.

Whilst fixing the emphasis stuff, it probably should be modified to allow for other text attribute handling, such as the additional emphasis requirements of UEB and also at APH we are thinking that transcriber notes could be handled in the same way as emphasis. Where I am going with this is that it might potentially lead to a change in the API which might not be backwards compatible, so we need to time it right so as not to disrupt releases.

How does solving it in liblouis compare to external/addon solutions? An external/addon solution would be to have functions which take a Braille string (preferably unicode Braille) and applies emphasis to that and adjusts the index values accordingly. If it was external then the restriction of only using C might not be necessary and so might be simpler to write. An external library could still be used by many and so should avoid the multiple implementation issue. Technically how does an external/addon solution compare with rewriting what exists? It may be useful should an organisation need to make a business case to justify doing the work in liblouis itself.

As i said I am not opposing doing it in liblouis, just I feel we need to consider these things.

Michael Whapples
On 19/11/2014 20:01, Mesar Hameed wrote:
Hi,

On Wed 19/11/14,19:47, Michael Whapples wrote:
We have been considering doing our own emphasis handling in the Java code of
BrailleBlaster, so we would be interested how others do such a thing and not
use liblouis for emphasis and whether any issues were encountered in doing
that.
It would be great if someone from Viewplus or APH could set aside some
development time to fix this directly in liblouis, this would probably be better
than attempting workaround solutions in braille blaster, this would fix
the problem at the source, and would only have to be done once.

Because in the past code has been added without any tests its hard to
know when/where or how something is working, if we add the examples you
provide as tests that would be a good starting point to trace through
the code and see how it behaves under the various examples, which might
give a hint where the code is going wrong.

thanks,
Mesar
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com

For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com

Other related posts: