[liblouis-liblouisxml] Re: Expanding the typeforrm parameter
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Wed, 16 Oct 2013 03:22:23 -0500
I am thinking of adopting Michael's suggestion to make the typeform
parameter like widechar. So instead of chr it would be defined as
something like typechar . Then typechar would be defined elsewhere in
liblouis.h.in to be either char or something longer. This would be
contrrolled by a parameter that could be set in the call to configure.
The configuration file in the windows subdirectory of the liblouis
tarball would also be changed.
Me4sar, I am wondering why you are suggesting an unsigned long integer.
We will never need that many kinds of different type indications in a
Braille document.
Thanks,
John
On Wed, Oct 16, 2013 at 09:02:39AM +0200, Mesar Hameed wrote:
> Hi John,
>
> On Tue 15/10/13,12:54, John J. Boyer wrote:
> > The reason for not using a larger data type is backward compatibility.
> > That is important.
>
> The following minimal invasive changes have to be done:
>
> 1. Change the public API in liblouis.h, to be unsigned long for
> typeform.
> 2. Do the matching changes in the function signatures in *.c files.
> 3. In *.c functions, anywhere the typeform array is copied, to temporary
> variables, change
> the definition of those temp arrays from char to unsigned long.
>
> Indexing into those arrays should all work out correctly, asuming that
> standard c array/pointer indexing was used.
>
> If you want, I can create a new svn branch where we can explore these
> thoughts.
>
> > It is also important to preserve the spacing
> > parameter.
>
> I don't think I understood why you felt that the spacing char array has
> to be the same type as the typeform array. The only requirement I can
> see is that it has to be the same length as the input string.
>
> I also understand your consern for backward compatibility, but since it will
> be a documented API change, and is a change which is good for liblouis, I
> don't
> see why external software should block us from doing the right thing.
> All it would require on their end is to change the external function
> calls to conform with the altered API and recompile.
> If their software is a compiled binary, and they don't have the sources,
> this is their problem, and they will have to accept that they can use
> the latest liblouis version before that API change. Tables can always be
> ported back by them, but they wouldn't get guaranteed results.
>
> Thats why organizations should buy development, rather than finnished
> products.
>
> thanks,
> Mesar
> > On Tue, Oct 15, 2013 at 05:16:38PM +0100, Michael Whapples wrote:
> > > This had also been going through my mind, why not just use a larger data
> > > type?
> > >
> > > I do not know enough about the internals to know what sort of impact
> > > this might have.
> > >
> > > Michael Whapples
> > > On 15/10/2013 16:31, Mesar Hameed wrote:
> > > >I haven't looked at the details of what might be required to do this,,
> > > >but since we are processing more than ascii in more recent versions of
> > > >liblouis, it might be worth considering changing the typeform from a
> > > >char array to a unsigned long int array.
> > > >That would give us a lot of additional bits, without the implicit
> > > >dependancy and complexity of always having to
> > > >decode both the intention by reading the mode and the typeform.
> > > >
> > > >thoughts?
> > > >thanks,
> > > >Mesar
> > > >
> > > >
> > > >
> > > >On Tue 15/10/13,15:04, Ken Perry wrote:
> > > >>My only concern here is how expandable will this be in the future if
> > > >>for
> > > >>example there turns out to be more than 12 needed?
> > > >>
> > > >>Ken
> > > >>
> > > >>-----Original Message-----
> > > >>From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
> > > >>[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> > > >>Boyer
> > > >>Sent: Monday, October 14, 2013 7:09 AM
> > > >>To: liblouis-liblouisxml@xxxxxxxxxxxxx
> > > >>Subject: [liblouis-liblouisxml] Expanding the typeforrm parameter
> > > >>
> > > >>Let me know if you have comments on the folowing.
> > > >>
> > > >>At present the typeform parameter can handle only four kinds of
> > > >>emphasis, bold, italic, underline and computer Braille. Although this
> > > >>parameter is a character array the high-order bits are used for the
> > > >>ascii numeric code, -x30. This is because at the beginning loblouis
> > > >>functions were called from Visual Basic.
> > > >>
> > > >>However, four types of emphasis are not enough to handle the Braille
> > > >>indicators required by modern textbooks, where it may be necessary to
> > > >>indicate colored type, script, etc.
> > > >>
> > > >>Therefore, I am proposing to use all eight bits of the typeforrm
> > > >>parameter. To preserve backward compatibility an additional bit in the
> > > >>mode parameter will be defined, extTypoeform . Since the spacing
> > > >>parameter is used only by ViewPlus and they may stop using it, I
> > > >>propose to make it an extension of the typeform parameter. This will
> > > >>provide 12 additional ways to indicate things in the text. It will
> > > >>also be controlled by the extTypeform bit.
> > > >>
> > > >>The present system of defining opcodes for things like beginning of
> > > >>phrase, end of phrase, etc for each type of emphasis is unworkable for
> > > >>an
> > > >>extended typeform parameter because it would result in a huge number of
> > > >>opcodes.
> > > >>
> > > >>The present algorithm for handling Braille indicators cannot be
> > > >>expanded
> > > >>for the same reason. Therefore, the correct-context-multipass feature
> > > >>will be extended with a scripting language. The base of this language
> > > >>already exists.
> > > >>
> > > >>John
> > > >>
> > > >>--
> > > >>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
> > > >>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
> >
> > --
> > 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
--
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:
