[liblouis-liblouisxml] Re: Fix for extra space after 'changetable'
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Mon, 7 Jul 2014 11:08:27 -0500
insert___translation may be called more than once in translating a block
of text such as a paragraph. This happens if different tables are
needed. For example, if a paragraph contains text followed by MathML
followed by more text then the literary text table will be used, then a
math table, then the literaryTextTable again. The math should ordinarily
be preceded and followed by a space. Of course, something more
discriminating could be used. If you like Paaul's solution you could try
it. A test to make sure it doesn't break something else would also be
nice.
John
On Mon, Jul 07, 2014 at 05:55:33PM +0200, Bert Frees wrote:
> John,
>
> You say that "the space is added to keep things from running
> together". Remind me, why exactly is that needed again? Is it because
> you remove space at an other place in the code? If so, shouldn't the
> logic that removes space be a little more conservative so that it
> doesn't remove space that has to be added again later?
>
> Bert
>
>
> Paul Wood writes:
>
> > Hi John,
> > We have looked at the code and found that the last 3 statements of
> > change_table.c are:
> > insert_translation (ud->main_braille_table);
> > ud->main_braille_table = oldTable;
> > pop_sem_stack ();
> >
> > This last 'insert_translation' calls the code I referred to in my
> > previous email and because the text being translated doesn't end with a
> > space e.g. 'a <abbr>US</abbr> state' then the 'insert_translation' code
> > ADDS a space. As the next bit to be translated starts with a space, we
> > end up with two spaces. There is nothing else that would add the space
> > in the next two lines. as far as we can tell
> > What we suggest is that the code does a look forward and if the next
> > character to be translated is a space then it doesn't add that space,
> > but otherwise it does. Is this a workable solution?
> > Suggested solution:
> >
> > The line is in 'transcriber.c' and is in the function
> > 'insert_translation (const char *table)'
> > It's replacing:
> > if (ud->translated_length > 0 && ud->translated_length <
> > MAX_TRANS_LENGTH &&
> > ud->translated_buffer[ud->translated_length - 1] > 32)
> > {
> > ud->translated_buffer[ud->translated_length++] = 32;
> >
> > with:
> > if (ud->translated_length > 0 && ud->translated_length <
> >
> > MAX_TRANS_LENGTH &&
> > ud->translated_buffer[ud->translated_length - 1] > 32 &&
> > ud->text_buffer[0]!=32)
> > {
> > ud->translated_buffer[ud->translated_length++] = 32;
> >
> > Thanks
> > Paul
> >
> >
> >
> > On 30/06/2014 17:03, John J. Boyer wrote:
> >> The space is added to keep things from running together. Your concern
> >> about breaking something is justified, since this is the function that
> >> handles all translations. The problem is more likely to be in the
> >> function that actually handles changetable.
> >>
> >> John
> >>
> >> On Mon, Jun 30, 2014 at 03:40:11PM +0100, Paul Wood wrote:
> >>> Hi Guys,
> >>> We have a university student volunteering with us for the summer! So
> >>> he thinks he has found the cause of the extra space after the
> >>> changetable opcode. I'm worried it will break something else and I
> >>> don't think we can run the checks as we are using windows.
> >>>
> >>> The line is in 'transcriber.c' and is in the function
> >>> 'insert_translation (const char *table)'
> >>> It's after:
> >>> if (ud->translated_length > 0 && ud->translated_length <
> >>> MAX_TRANS_LENGTH &&
> >>> ud->translated_buffer[ud->translated_length - 1] > 32)
> >>> {
> >>>
> >>> and is:
> >>> ud->translated_buffer[ud->translated_length++] = 32;
> >>>
> >>> He tells me 32 is the ascii for space, so basically it's adding a space.
> >>> Please tell me if we can do the checks under windows and what else
> >>> we need to do ie. create a fork etc.
> >>> Thanks
> >>> Paul
> >>>
> >>> --
> >>> Paulw.torchtrust signature
> >>>
> >>> Paul Wood, Chief Technical Officer
> >>> *Torch Trust*
> >>> Torch House, Torch Way,
> >>> Market Harborough, Leics. LE16 9HL, UK
> >>> Direct Line: *+44(0)1858 438269*
> >>> Tel: *+44(0)1858 438260*, Fax: *+44(0)1858 438275*
> >>> Email: paulw@xxxxxxxxxxxxxx <mailto:paulw@xxxxxxxxxxxxxx>
> >>> Website: www.torchtrust.org <http://www.torchtrust.org/>
> >>>
> >>> ____________________________________________________
> >>>
> >>> Chief Executive: Dr Gordon Temple
> >>> Charity No. 1095904
> >>>
> >>> Privileged/Confidential Information may be contained in this message.
> >>> If you are not the intended recipient please destroy this message
> >>> and kindly notify the sender by reply email. The computer from which
> >>> this mail originates is equipped with virus screening software.
> >>> However Torch Trust cannot guarantee that the mail and its attachments
> >>> are free from virus infection.
> >>>
>
> 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:
