Regarding grouping the characters into advanced or commonly used
characters, there was a good reason for this.
Unicode defines three private use areas. The one in the range
u+e000-u+f8ff and the other two requiring UCS4 (32-bit unicode) to be
represented. These higher private use areas thus would be unavailable to
UCS2 builds of LibLouis.
As the u+e000-u+f8ff only has 6399 characters available and assuming
that everything below u+f000 has been used by MathType (as that is where
you started LEAN and MathType private use is your main concern not to
clash with) we have less than half of the characters available.
If we were adding characters for other uses then this might not be
enough, I only say might as it depends on how many other uses are to be
included (eg. would Clingon be in scope for inclusion, personally I
think no but I am not into StarTrek and so its not important to me) and
I don't know what the standard unicode coverage is for those other
specialist uses is like.
So it seems logical to move characters rarely used (eg. used by 1
percent of users) to the higher private use areas and require those
users to use UCS4 builds of LibLouis. I would only be moving those in
the LEAN set which supplement the standard unicode definitions and not
any of the standard unicode definitions.
Having read through your LEAN characters list, I don't think there is
anything there which is sufficiently rare to warrant moving it to the
other private use areas. Thus it probably is only if we create more LEAN
characters we should consider whether it is commonly used enough to need
to go in the u+e000-u+f8ff range or whether it is advanced and belongs
in the higher private use area.
Michael Whapples
On 15/04/2016 15:45, John Gardner wrote:
Michael, I avoided putting characters into the private area used by Design
Science. I am not aware of any other math-related private Unicode uses, but if
there are any, I would want to avoid them.
Michael, I do not see any point to grouping symbols in the code table. You
surely do not want to re-invent standard Unicode symbols so you will be using
symbols from all over unicode's first sheet. The LEAN symbols are defined and
are being used by LEAN Math Editor, and I really do not want you to move them
and make LEAN inconsistent with something else. It makes perfect sense to me
that you should define groups of symbols for different math levels. In fact
ultimately it may be that there would be groups for different subjects. But for
heaven's sake, we do not want the different sets to have different code
positions such that symbols that appear in one set have different code
positions than the same symbols that appear in another set.
John
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples
Sent: Friday, April 15, 2016 2:26 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: UEB unified english braille support;
A small question, why did you only use characters above u+f000 when the private
use area starts at u+e000? Is there any other standards (eg.
STIX project) which you wanted LEAN to work with?
Michael Whapples
On 14/04/2016 17:40, John Gardner wrote:
Keith, FYI I am pasting in the LEAN character set below. The code avoids theFor a description of the software, to download it and links to project pages go
MathType private Unicode set and is pretty well organized up to the final few
characters that were added after the set had been developed. I fear that adding
characters will continue to be necessary, so beautiful organization is probably
not the best goal.
John G
Characters used for math as function of unicode position # marks headings.
#MathType Fonts
F000-F019 Fraktur capital letters
F01A-F033 Fraktur small letters
F080-F099 Bold capital letters
F09A-F0B3 Bold lower case letters
F0C0-F0C9 bold 0 through 9
F0CA bold Nabla
F0CB bold Euler Constant
F100-F119 Script capital letters, many missing
F011A-F0133 Script lower case letters
#New LEAN characters
#F200-F219 Math Capital letters
#F21A-F233 Math lower case letters
#MathVariant Attributes
F300=Bold
F301=Italic
F302=Fraktur
F303=Script
F304=SansSerif
F305=Doublestruck
F306=MonoSpace
F307=Normal Font
#MathSize attributes
F308=Small
F309=Big
F30A=Normal Size
#Scripts
F320=SubScript
F321=SuperScript
F322=UnderScript
F323=OverScript
F324=Left SubScript
F325=Left Superscript
#Structures
F326=Expression
F327=End Expression
F328=Fraction
F329=End Fraction
F32A=Root
F32B=End Root
F32C=Root Index
F32D=Fraction Seperator
F32E=Math
F32F=End Math
#Table markup
F330=Table
F331= End Table
F332=Row
F333=End Row
F334=Cell
F335=End Cell
F336=Row Span
F337=Cell Span
#Miscellaneous LEAN symbols and modifiers F338=Color F339=Background
Color F33A=Variant F33B=Size F33C=Attribute F33D=End Attribute F33E=no
line F33F=Label F340=end label F341=numerator F342=from F343=to
#MathColor attributes F350=aqua F351=black F352=blue F353=fuchsia
F354=gray F355=green F356=lime F357=maroon F358=navy F359=olive
F35A=purple F35B=red F35C=silver F35D=teal F35E=white F35F=yellow
#Convenience symbols F390=Squared F391=Cubed F392=end
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Keith
Creasy
Sent: Thursday, April 14, 2016 9:13 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: UEB unified english braille
support;
I think this is a great idea. I'm in favor of not only using it but making your
character set the defacto standard for math tables. It just makes sense.
In any case we all need to agree if possible as to avoid confusion and
conflicts.
Thanks.
Keith
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of John
Gardner
Sent: Thursday, April 14, 2016 11:49 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: UEB unified english braille
support;
Keith, I volunteer to do this for presentation MathML. There are only a few
MathML elements that need decisions. I can write down the tradeoffs and give my
notes to a MathML expert or two to be reviewed before sending them to the list
for discussion/decision.
John G
John G
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Keith
Creasy
Sent: Thursday, April 14, 2016 5:55 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: UEB unified english braille
support;
Examples are good but we really should use the documentation on MathML 3 as a
guide. We'll also probably need help from people who are expert at the various
math codes. A first step might bee to review MathML 3 and identify which
elements, attributes, and operators need to be addressed by LibLouis, the
formatter, or perhaps neither.
Find the documentation at https://www.w3.org/Math/draft-spec/Overview.xml.
Keith
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of
Michael Whapples
Sent: Thursday, April 14, 2016 8:43 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: UEB unified english braille
support;
That is a good point.
In a way it is difficult to deal with this without examples, but equally I
would prefer not to just handle examples and then find we miss something.
For the examples you give. The different styles of fraction, not sure about UEB
but in UK Braille I do not think there is any way to distinguish between those.
Even if it were to be important, I guess it is just another character
assignment, one for slash (/) which we could always just use the / character,
and one for horizontal line (vertically laid out fractions).
On the vertical alignment and spacing, I am not sure how this gets represented
in Braille, but should it end up being vertical placement in Braille then we
are going beyond what LibLouis does anyway and its really a job for our
formatters.
The reason I feel this should work is that LibLouis can only take a string
input along with a typeforms array, so unless we plan to modify LibLouis
function calls it has to go in a string.
The only thing I also see as a possible issue based on what you said,
if to support everything whether we run out of characters. In the
u+e000-u+f8ff range there are 6399, which on its own may be an issue.
However consider the other two private use areas and I think we have no issue
(eg. from the u+f0000-u+ffffd area we get 65533 alone).
Considering the UCS2 restriction, I would therefore put the most common math in
the u+e000-u+f8ff area with the advanced math characters in either of the other
two.
The only other issue with number of characters is whether LibLouis needs other
private use characters commonly available. If so it may be worth having some
way to indicate start of a type (eg. math) so that these private use characters
could be reused in different contexts. The other way to solve that one is to
use typeforms to indicate the way these private use characters should be
handled but I am not sure whether that is too good (I know we have kept running
out of typeform bits).
Michael Whapples
On 14/04/2016 12:24, Keith Creasy wrote:
Keep in mind that we plan to do a lot of things that go above and beyond theFor a description of the software, to download it and links to project
current LibLouisUTDML support. MathML has such things as vertical alignment and
spacing; and an attribute that indicate whether a fraction is expressed
vertically (with a horizontal line to separate the numerator and denominator)
or horizontal (using a slash. There may even be others that I'm not thinking
of. We hope to be able to correctly translate and format even fairly complex
MathML.
Keith
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of
Michael Whapples
Sent: Thursday, April 14, 2016 7:08 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: UEB unified english braille
support;
What I described whould not need to all happen at once. The common text format
may initially only be used for UEB, but over time may be the other codes could
be moved to it as well.
As an example take a fraction. In Nemeth.sem the third column is ^?,/^# and in
ukmaths.sem the third column is \x0003,@456-34,\x0004.
My thought is that for the three parts of a fraction we may define the
following private unicode characters:
* u+e002 Start fraction
* u+e003 over indicator.
* u+e004 end fraction
Then in the math.sem file the third column would be \xe002,\xe003,\xe004. The
UEB tables from the start may be designed to work with these and then over time
the nemeth table could be altered to stop looking for ^? and look for \xe002
instead. Likewise with the ukmaths.sem file.
Admittedly fractions may be a simple case and may be I will hit problems later
on. I have not yet investigated UEB enough to be certain with UEB, but looking
at the three maths codes' .sem files in LibLouisUTDML, this all looks very
doable and not too complicated and I don't foresee issues with those.
My thought in doing this is that if there is a common text language for
communicating maths to LibLouis then this could be used by any software wanting
to do math translation, regardless of the source format. Under the current
situation the software would need to do different stuff depending on the
Braille code it wants out and seems like a lot of work.
As we are needing to do math translation without LibLouisUTDML already in APH,
I feel the work in doing this common text format will be no more, possibly
less, than doing the other options available.
Related to this, I am planning to use the private use area between
u+e000 and u+f8ff. My thought with this is that then it will be
available regardless of LibLouis being compiled with UCS2 or UCS4. Does anyone
see an issue with this, might there be other private use standards we may want
to use within this range?
Michael Whapples
On 14/04/2016 11:39, John J. Boyer wrote:
Hi Michael,For a description of the software, to download it and links to
A common linear text for the different mathematical codes is
certainly possible. The Nemeth .sem file and liblouis tables were
developed first and were prodeucing very good results. I didn't want
to monkey with them. It was safer to take a fresh approach with
UKMaths. Keith says that UEB math can be handled by liblouis by adding it to
the UEB tables.
Of course, the MathML has to be handled by something else.
I'm not sure that developing a single text string to replace the
existing .sem files is a good use of your time.
John
On Thu, Apr 14, 2016 at 10:34:08AM +0100, Michael Whapples wrote:
Thanks for that. It is always best to check if people previously
hit issues when trying to do something similar.
Having worked through the .sem files, I feel that at least for the
three already in LibLouis that a common text format could be created.
I am thinking of possibly using the private use unicode block.
Whilst it probably will be heavily influenced by the LibLouisUTDML
existing .sem files, the private use character assignments probably
will more relate to semantic meaning (eg. begin fraction, end
fraction, begin table cell,
etc) rather than just getting the correct Braille (I noticed a
number of things in the .sem files where the Braille was the same
but it meant something different). My thought being that the
LibLouis table can always translate the different characters into the same dot
pattern.
My thought with this is that the processing of the MathML can be
done in one way regardless of the Braille code and the Braille code
is only determined by the LibLouis table used. In LibLouisUTDML
terms this would mean a single math.sem file and the liblouis
tables are what give you UEB, Nemeth, UK maths or Marburg.
The main risk I see is that in focusing on the four Braille codes I
mention above that if someone tries to add another math Braille
code then may be the text format will not quite be sufficient.
Hopefully in such a case it would be possible to add additional
character assignments to maintain the information needed and the
four existing codes can just ignore those additional characters.
There is a risk of a Braille code being laid out in a different way
and so needing different semantic action files. This I think is a
risk I am prepared to take, we could get stuck considering the
problem too much and not getting anything done and it might be
questionable whether for something differing so much whether a common text
format could even be achieved.
Michael Whapples
On 14/04/2016 01:09, John J. Boyer wrote:
The reason the nemeth.sem and the ukmaths.sem files are soFor a description of the software, to download it and links to
diffieent is that i learned as i developed. By the time the
UKMaths was needed i had realized that it would be much better to use dot
patterns.
There was never a question of a common linear text. UKMath
required a lot of additional code. It was much more difficult to handle than
Nemeth.
John
On Wed, Apr 13, 2016 at 02:35:32PM +0100, Michael Whapples wrote:
As Keith mentioned APH are looking at UEB math in BrailleBlaster,
but this won't be through LibLouisUTDML.
Regarding LibLouisUTDML, I have some questions for John. I notice
that the Nemeth.sem file has some sort of escape sequences, based
on the Nemeth symbols. In contrast the UK Maths and Marburg files
seem to do a lot more by using the dot patterns. I know that the
Nemeth.sem file was developed first with the other two coming later and may be
from other contributors.
However this raises the question why a common linear text format
was not used? Looking at the .sem files other than the third
columns these seems to basically be the same, which to me implies
what is passed to liblouis is structurally the same. What I am
trying to get at, was there a technical reason why a common
linear text format was not used for all three or is it more to do
with them being developed at different times and never quite getting to it.
Michael Whapples
On 13/04/2016 07:10, John J. Boyer wrote:
I don't know if anyone is working on UEB math. However, UKMathsFor a description of the software, to download it and links to
and Marburg maths are already supported. UEB maths should not be
a big problem.
John
On Wed, Apr 13, 2016 at 04:28:21AM +0100, tolga karatas wrote:
--
many thanks,
tolga
Dear Sir/madam;
I am a blind/visually impaired student studying a degree in
computing; I am using the focus 40 braille display;
I was wondering when UEB maths support is going to be available please?
Yours Faithfully;
Tolga Karatas
For a description of the software, to download it and links to
project pages go to http://liblouis.org
project pages go to http://liblouis.org
project pages go to http://liblouis.org
project pages go to http://liblouis.org For a description of the
software, to download it and links to project pages go to
http://liblouis.org
pages go to http://liblouis.org For a description of the software, to
download it and links to project pages go to http://liblouis.org For a
description of the software, to download it and links to project pages
go to http://liblouis.org For a description of the software, to
download it and links to project pages go to http://liblouis.org For a
description of the software, to download it and links to project pages
go to http://liblouis.org
to http://liblouis.org
For a description of the software, to download it and links to
project pages go to http://liblouis.org
