Re: MS Math layout (was: ZWJ, ZWNJ and VS in Latin and other Greek-derived scripts)

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Tue Jan 30 2007 - 15:46:46 CST

  • Next message: Rick McGowan: "Public Review Issue #75: UTR #25 draft updated"

    From: +ACI-John Hudson+ACI- +ADw-john+AEA-tiro.ca+AD4-
    +AD4- Ruszlan Gaszanov wrote:
    +AD4-
    +AD4APg- As for formula editors, I'm not sure about Open Office, but MS Word equation editor was written long before mathematical alphabets were encoded in Unicode. I'm not sure how it encodes the variables internally, but in any case, those variables are encoded as regular letters in PDF.
    +AD4-
    +AD4APg- I'm not sure if Microsoft is planning to rewrite their equation editor anytime soon, or are they going to use characters from mathematical alphabets if they do, but I know for sure that many users will be using current versions of MS Word for years from now for writing mathematical and technical texts among other things.
    +AD4-
    +AD4- Point of information:
    +AD4-
    +AD4- Office 2007 includes a completely new math layout handler, math input language, math font.

    And there are other areas where technical editing is needed:
    +ACo- chemical formulas
    +ACo- electricity, electronic
    +ACo- complex table layouts (you may import some from Excel, but Excel lacks many features needed to implement such tables easily)

    But I do agree that most of this does not belongs to text editing. Most of these will be better supported using W3C's SVG format along with CSS formating and automation through scripting. This leaves place for many object editor addons, provided that Office correctly supports the standard formats. For now, the support in Microsoft tools is quite poor face to Adove products for such editing.

    In the free software area, there are SVG graphic editors, but none of them allow simple automation, which is needed by scientists to create graphics from formulas, automate the generation of object forms from mathematical constraints, symetries, intersections, angles, parametric equations, and allow transforming those objects while keeping the constraints, and the style.

    Now all those graphics very often need to be annotated, using internationalized text+ADs- those tools need to support Unicode, and this is where XML-based formats (like SVG) are interesting because the support of Unicode is required in all XML implementations.

    What is still missing is tools that allow manipulating the annotated XML formats, and simplifying them before publication (removing the unnecessary design constraints from these files, because they take significant resources to process, even for the final rendering, or to transfer).

    The next thing that we are missing is to allow users to create their own fonts easily for their documents. SVG is an interesting format for glyphs, but a standard packaging format for SVG-based fonts is still missing, and their support in various tools is very limited (except when the document gets converted into the PDF packaging format, where all the static text becomes vector graphics).

    The OpenType font format is definitely not easy for users that want to publish texts using the custom glyphs they need or containing texts whose script is still not, or is poorly supported in lots of OS'es. The tools required to create portable fonts are really too complex, when users just need fonts that can be used to create documents within their owncontext, and not necessarily a lots of alternate languages.

    The final problem is realted to the customization of font collections+ADs- it's still not easy to create and manage an aggregate collection as if it was a single font, where users can select the styles from various other fonts (or even from their own set of user-created glyphs with simpler formats like SVG). There's a need for making such custom virtual fonts manageable by users instead of by font designers.

    And such virtual font format should be accepted and work in the most common text renderers (including those used in browsers). Virtual fonts would solve definitely the interoperability problems between platforms+ADs- for example, instead of specifying font styles in documents, the documents would specify only the language+-script pair and the style only as a least significant variant, and virtual fonts would be used automatically according to these linguistic preferences.

    The current solution used in all existing browsers do not work correctly without forcing users to download and install lots of fonts (whose versions are important for correct rendering, but not specified in documents+ACE-) This is an excellent reason why the PDF format is so popular: if the document can be created by the author with his own resources, then he can produce a document that can be rendered/printed everywhere (in its original layout only), because almost all system-dependencies are removed when converting the text to graphics...

    For publishing, this is generally all what is needed+ADs- but for working on documents (and allowing reaggregation or quotation, or to change the layout for republications ondifferent supports), or only allowing modifications in a working team, or in data management and transformation softwares, or correct indexation by text search tools, the PDF format is definitely +ACI-not the panacea+ACI-... (not sure that this expression exists in English, look at its evident French origin).



    This archive was generated by hypermail 2.1.5 : Tue Jan 30 2007 - 15:48:51 CST