In that case I agree with this. Thanks, Mesar On Wed 16/10/13,16:39, Michael Whapples wrote: > I think what I had been suggesting was that typechar (if we want to > call the type that) would be a defined size for any given version, > but could be increased in size in future versions. > > Thus liblouis 2.6.0 might have typechar defined as being width > 16-bit, but if by liblouis 2.8.0 we felt we needed more bits we > could define it in 2.8.0 as 32-bit, etc. If a developer relied on > 32-bits in typechar then they would need to depend on liblouis 2.8.0 > or higher. > > I think it might be not so good if typechar could be different > widths in one version depending on how it is compiled, but that > might be due to my background in languages like Java and Python > where one normally does not have conditional compilation. > > Any version numbers I have given here are purely for illustration > and do not indicate when I feel what should happen. > > Michael Whapples > On 16/10/2013 10:06, Mesar Hameed wrote: > >Hi, > >On Wed 16/10/13,03:22, John J. Boyer wrote: > >>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. > >This doesn't seem quite right, because this would mean at any given > >release, the liblouis code could be compiled with a smaller number of > >bits than might be needed by documented functionality. > >I.e. documentation might say we need 16 bits, yet someone goes and > >compiles typeform defined as chars. > > > >I know this is speculative since we are only using 4 bits at the moment, > >but we want to be forward extensable too. > > > >>Mesar, 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. > >Unsigned long or unsigned int, whichever seems more realistic I don't > >mind, I am unsure of the number of > >bits we might need, but my thinking is that unsigned long is fixed size > >yet large enough to give us a lot of bits > >for future needs. > >At the same time everyone knows how to convert to it > >from short ints, ints and so on. > > > >I have long term ideas for liblouis enhancements, and how that might be > >communicated to the translator. > >For example if mathematics was indicated, then we might switch from the > >default translation table to maths tables. > >Another sinario is if the text contains multiple languages, for example > >a textbook for learning a foreign language. > >We might want to indicate that this segment should be translated using a > >secondary or third table. As in an English document, which contains both > >French and German text. > >The solution from a braille production system might be to use > >liblouisutdml, but for a screenreader this is probably not viable > >because it most likely is accessing information on a line by line basis. > > > >This is an entire discussion on its own, but these are just some ideas on > >why we don't want to restrict ourselves > >when future proofing. > > > >thanks, > >Mesar > > > >>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 > > 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
