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
Attachment:
signature.asc
Description: Digital signature
