Get MathML working on OS/2




16 years ago
15 years ago


(Reporter: jhp (no longer active), Assigned: jhp (no longer active))



Firefox Tracking Flags

(Not tracked)



(2 attachments, 2 obsolete attachments)



16 years ago
Need to get MathML working on OS/2.  To start off with, need to implement
GetBoundingMetrics functions, and facilitate loading of MathML fonts.

Comment 1

16 years ago
Created attachment 77120 [details] [diff] [review]
initial patch

Comment 2

16 years ago
Created attachment 77125 [details] [diff] [review]
screen capture

Here is a screen shot of what MathML functions look like now on OS/2.  I get
the messages that the MathML font properties files are being loaded for all the
listed fonts, but everything looks like garbage.  Does anyone have any ideas
why this is happening?

Comment 3

16 years ago
Created attachment 77126 [details]
screen capture
Attachment #77125 - Attachment is obsolete: true

Comment 4

16 years ago
-> re-assigning to pedemont since he is doing the port...

GetBoundingMetrics: checkout the testcases on bug 124543 -- they uses only ASCII
characters. If you get the same graphical bounding boxes, then you are done.

Then, fixing the garbage is is the next step.
Assignee: rbs → pedemont

Comment 5

16 years ago
rbs:  I went to the test case in 124543, and for MathML, the "jif" string was
garbage.  After some debugging, it turns out that OS/2 is trying to render the
lower case letters using the font cmsy10, which doesn't have lower case
characters, only uppercase.  If I remove the font cmsy10 from the system, then
that testcase renders correctly.  This is going to be a problem with MathML on
OS/2.  On OS/2, we cannot ask a particular font if it supports a particular
glyph.  Therefore, mozilla cannot know that it cannot render the lower case
string "jif" with cmsy10.
We had a similar situation with Unicode.  Most fonts on OS/2 do not support
Unicode codepage;  there is only one such font that is installed with the system
by default.  We created a hack in ResolveForwards() whereby if one of the
characters is in the unicode range, then we always render with that font; 
otherwise we render with the given font.
There might be a way to do the same with MathML, maybe using the MathML font
properties files.  However, I don't know enough about this to be able to devise
such a hack.  Do you have any ideas, rbs?

Comment 6

16 years ago
I had a quick look at the OS2 font code and it reminded me of what the Windows 
code is doing for the 'A' versions (the code used by defaut on Win95-Japanese 
where Unicode support is buggy). The corresponding sublass is nsFontMetricsWinA 
which only relies on piecewise Ansi code pages. Is it the kind of things that 
you are stucked with by default on OS2? But I noted that you are not (yet) 
setting up the font maps which will allow testing the math fonts by name and 
building their own maps so that you can have a list of characters that are in 
these fonts.

So you really have to get the lingering '#ifdef WINCODE' that I saw in your code 
to first work, otherwise you won't make much sense of the math fonts. Using 
WideCharToMultiByte() on these fonts will just produce incorrect results.

Getting the '#ifdef WINCODE' to work involves building the font maps and setting 
up the |fontHasGlyph| helpers based on these maps. From there on, you can test 
math fonts by name and fetch their custom maps using 

Comment 7

16 years ago
Created attachment 81010 [details] [diff] [review]
patch w/ changes from 140096

patch includes changes based on bug 140096 (WideCharToMultiByte).
Attachment #77120 - Attachment is obsolete: true

Comment 8

15 years ago
We're not going to fix this for OS/2.

Without the ability to query glyphs from the fonts, there isn't anything we can
do to make MathML work.
Last Resolved: 15 years ago
Resolution: --- → WONTFIX

Comment 9

15 years ago
I find it hard to believe that OS/2 has no way to check glyphs in a font,
meaning that equation editors can't be developped for such an Operating System?
It is even more a paradox because the TrueType format specifically includes
so-called "OS2" tables which are supposedly meant for OS/2. Rather that
"inability" (which is synonymous with "IBM was too short-sighted when developing
such a lousy OS"), I am led instead to believe that this bug might involve
parsing the TrueType font, if no high-level utility functions are provided as
with other OSes. Since OS/2 utlimately needs to render characters from TrueTrype
fonts, it is strange that no such utility functions exist.

Comment 10

15 years ago
Actually, we are working with a third party to create a way for us to query
glyphs from font.

But we believe that all the work in this bug won't be relevant in that context.

OS/2 does have SERIOUS font deficiencies and parsing the TrueType fonts isn't
good enough, since OS/2 has Adobe fonts and bitmap fonts as well.

Once we have the new glyph code, we'll revisit MathML, but we don't have a
requirement for it on the OS/2 platform. We're just not mainstream :)
You need to log in before you can comment on or make changes to this bug.