[liblouis-liblouisxml] Re: Issue with emphasis

  • From: Larry Skutchan <lskutchan@xxxxxxx>
  • To: "liblouis-liblouisxml@xxxxxxxxxxxxx" <liblouis-liblouisxml@xxxxxxxxxxxxx>
  • Date: Thu, 20 Nov 2014 11:42:01 +0000

Isn't part of the issue that one cannot represent some of the target indicators 
in ASCII? How, for example, does one represent bolding, italics, or underlining 
in a text file?
My understanding is that UTD is also a means of passing much more rich 
information to the translator.



-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx 
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples
Sent: Thursday, November 20, 2014 6:33 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Issue with emphasis

My only question of that is, if the case for doing it in liblouis is so strong, 
why have so many done their own hack work arounds outside liblouis rather than 
fixing liblouis and submitting a patch? What is it that everyone is missing in 
the fixing liblouis solution?

There must be something in the external solution idea which has lead people 
that way.

I am suggesting that the increased complexity of the external solution cannot 
be too big as it seems preferable compared to working with liblouis code.

Additionally I would suggest that having to work in C increases the difficulty 
as one looses some of the features of higher level languages (eg. string 
manipulation libraries, object orientation, etc).

Michael Whapples
On 20/11/2014 10:38, Bert Frees wrote:
> 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

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: