[liblouis-liblouisxml] Re: Issue with emphasis
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Thu, 20 Nov 2014 06:55:59 -0600
Sometime ago I made the width of the typeform parameter adjustable via a
#define. It should be at least unsigned short, but this would involve
considerable code changes.
We could get rid of the spacing parameter.
John
On Thu, Nov 20, 2014 at 11:38:30AM +0100, 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
--
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
