[liblouis-liblouisxml] Re: Please don't misunderstand the importance of what John Boyer is saying
- From: Ken Perry <kperry@xxxxxxx>
- To: "liblouis-liblouisxml@xxxxxxxxxxxxx" <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Sat, 26 Oct 2013 20:01:46 +0000
I think if we went straight from xml to braille the type form would be handled
by the xml tags. There is no reason to remember the state and pass it if we
can do it all in one parser and there are more difficult xml transformmers out
there braille translation can be just another one of those. I think that
translating a regular text file should just be an extention of a parser that
parses braille xml for example if I have a text file and I want to convert it
to braille it's easy to stick xml tags as you load the file around the entire
ttext than it is to remove all the type format information from an xml file and
pass it in to a braile translator.
Ken
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples
Sent: Saturday, October 26, 2013 3:25 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Please don't misunderstand the importance
of what John Boyer is saying
I agree that regex could probably do all the text processing. However everytime
it is raised comments are made as to it not handling typeform.
Have you a suggestion for how it can deal with that?
I personally have questions over how typeform is handled and whether that way
really is needed. Would it really be that problematic to embed tags such as XML
in the translation string and still preserve indexing, I would have thought it
is fully possible. May be I need a further explanation as to why embedding tags
would cause problems, and examples might be useful.
Michael Whapples
On 26/10/2013 19:44, Ken Perry wrote:
> This could all be handled by a regex opp code in the current liblouis though.
>
> Ken
>
> -----Original Message-----
> From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
> [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Susan
> Jolly
> Sent: Saturday, October 26, 2013 2:15 PM
> To: liblouis-liblouisxml@xxxxxxxxxxxxx
> Subject: [liblouis-liblouisxml] Please don't misunderstand the
> importance of what John Boyer is saying
>
> I think we are using the term "scripting language" in two different
> ways that is leading to misunderstanding and confusion,
>
> Certain existing programming languages such as Python are often referred to
> as scripting languages. You can read more about the use of this term in this
> Wikipedia article:
> http://en.wikipedia.org/wiki/Scripting_language
>
> I believe John Boyer is using this term as a synonym for what is also called
> a Domain Specific Language or DSL. He is not advocating developing a language
> such as Python. The concern is that we definitely need some high-level and
> uniform way for people familiar with the rules of a particular braille code
> to express or encode the possibly quite complex rules for the use of
> indicators in that code.
>
> As an example of the complexity of these rules I will contrast some of the
> rules for the use of the number sign in American English braille and in UEB.
>
> In our current English braille (EBAE) a single number sign is used before a
> braille sequence to indicate integers, real numbers, and also numeric
> sequences. A numeric sequence consists of digits plus one or more of six
> special characters: colon, comma, decimal, fraction line, hyphen, and slash.
> That is, the scope of the number sign is not terminated by any of these six
> characters but it is terminated by a space, slash, letter, etc.
>
> There are also various rules for when a letter sign is needed if a letter or
> group of letters immediately follows a number. In older versions of EBAE a
> letter sign was only needed to avoid ambiguity where the same braille cell
> could represent a letter or digit. The latest rule is that a letter sign is
> always needed if a letter immediate follows a number or is joined to it by a
> hyphen with the exception that if a single letter is immediately followed by
> another number sign, then the letter sign is not required.
>
> The rules for the use of the UEB numeric indicator are quite different from
> the EBAE ones. In the first place, the indicator is actually two cells.
> The first cell is always the standard dots 3456. The second cell can be a
> digit, a period, a decimal point, a comma, a space, or, if necessary, a
> second dots 3456. There are six symbols that don't end the scope of the
> indicator. Also the dot 5 numerical space doesn't end the scope if it is
> immediately followed by another digit. The UEB numeric indicator also
> establishes a special Grade 1 mode unless terminated by a hyphen or dash.
> This means that in many cases contractions cannot be used immediately after
> numbers.
>
> I hope it is clear from just this one example that this is a very serious
> issue that is going to require a lot of thought.
>
> Susan Jolly
>
>
>
>
>
>
> 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
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
