[liblouis-liblouisxml] Re: Expanding the typeforrm parameter
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Wed, 16 Oct 2013 08:13:14 -0500
The spacing parameter is used by ViewPlus to determine which spaces in
the output correspond to which spaces in the input. I have never liked
it. It is a holdover from the early days. Since ViewPlus will soon be
using utd, it will soon be unnecessary.
Since we're talking about changing the API by making typeform a larger
size, we might as well consider dropping the spacing parameter also.
How soon do people thing changes in the API should be made? A lot of
applications will need tweaking.
John
On Wed, Oct 16, 2013 at 11:40:58AM +0000, Keith Creasy wrote:
> OK, I confess ignorance. What does the "spacing parameter" do?
>
>
>
> -----Original Message-----
> From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
> [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer
> Sent: Tuesday, October 15, 2013 1:54 PM
> To: liblouis-liblouisxml@xxxxxxxxxxxxx
> Subject: [liblouis-liblouisxml] Re: Expanding the typeforrm parameter
>
> The reason for not using a larger data type is backward compatibility.
> That is important. It is also important to preserve the spacing parameter.
> The typeform and spacing parameters together give 16 bits, of which 4 are
> already committed. That should be enough to handle colored type, script, etc.
> the 12 uncommitted bits can be used for anything in the particular document.
>
> John
>
> 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
> 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:
