I would have thought though doing what you suggest causes longer term pain as its certainly not the most obvious, natural or cleanest way to implement such a feature.
Good design probably requires less modification in the future and so is possibly the best protection for long periods of backwards compatibility.
Also if the data types of the typeform array was an alias of the primitive data type, it would still be backwards compatible when you increase the data type size (eg. int to long int) wouldn't it? It would be like how widechar can have different widths.
Upgrading to a new API is something one only needs to do once, dealing with the API is something one needs to do every time writing or maintaining code which uses the API. Therefore I would put more emphasis into ensuring the API is good to use.
Having a mode bit which changes the meaning of a parameter to me sounds horrible and I am unconvinced on the future proof of this approach.
Michael Whapples On 15/10/2013 20:08, John J. Boyer wrote:
Good points about design. However, 16 typeform bits, with 4 reserved for existing emphasis types seems enough for any reasonable document. We must also preserve backward compatibility. It should not be broken unless there is a very good reason for it. This is the reason for retaining both the typeform and spacing parameters as character arrays and using an additional mode bit to turn on extended typeform handling and use of the scripting language. John On Tue, Oct 15, 2013 at 05:56:38PM +0000, Ken Perry wrote:You say we don't have to worry about it for a while. The thing is when you spend 90% of your time in design you only need to spend 10% of your time in coding. If we just say hey we won't need this for a while that is not design based coding and will mean in the long run we will spend more time trying to fix a limitation like not having enough spots. This is the time we should code for the future so that when we hit that limitation we don't have to spend a year trying to find a way to make everyone happy who are now used to using the char based limited binary field. Ken Ken -----Original Message----- From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer Sent: Tuesday, October 15, 2013 1:49 PM To: liblouis-liblouisxml@xxxxxxxxxxxxx Subject: [liblouis-liblouisxml] Re: Expanding the typeforrm parameter Well, 12 is a lot. I don't think we have to worry about it for a while. Also, the bits can be ored together, as for combined bold and italic emphasis. John On Tue, Oct 15, 2013 at 03:04:21PM +0000, 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-- 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
