[liblouis-liblouisxml] Re: Issue with emphasis
- From: Bert Frees <bertfrees@xxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Thu, 20 Nov 2014 11:38:30 +0100
A key point is that all the behaviour including text-level formatting should be
programmable in a single file format (i.e. the liblouis table). I don't see how
an external solution could be better than including the logic in liblouis
itself. It can only make things more complex.
Re: the possible backward compatibility issue, I'm hoping the typeform argument
can be extended to cover all the UEB requirements and more. If not, we could
introduce an additional function that accepts a typeform with a bigger width
(currently it's a byte).
Bert
James Teh writes:
> Hi.
>
> On 20/11/2014 9:34 AM, Michael Whapples wrote:
>> 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,
> Unless I'm missing something, I imagine transcriber notes could just be
> another typeform flag applied to the text of the note. liblouisutdml can
> then use this typeform flag when processing the markup. At least for
> liblouis, I can't see this causing backwards compatibility issues.
>
>> How does solving it in liblouis compare to external/addon solutions?
> An external solution:
> * Increases complexity. Increased complexity means it is more error
> prone. For example, you have to deal with multiple levels of indexing.
> There's already quite enough of that confusion in the liblouis code. :)
> * Means additional dependencies. We already have two libraries: liblouis
> and liblouisutdml. An external solution means a third.
> * Complicates testing. Testing this stuff in a single project is hard
> enough. Testing it across several projects is somewhat more difficult,
> not least from a build perspective.
> * Complicates maintenance, since we have to manage yet another library.
>
>> it was external then the
>> restriction of only using C might not be necessary and so might be
>> simpler to write.
> True, but it also introduces a dependency problem. For example, if we
> wrote it in Python, that makes integration difficult for Java
> programmers and vice versa.
>
> All of that said, I imagine fixing this in liblouis is going to be quite
> difficult, so I can certainly understand the desire to avoid doing so.
> However, if we keep patching the internal problems by creating external
> solutions to fix them, things will get worse in another direction.
>
> Just my AU$0.02 worth.
>
> Jamie
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
