65901 - reminder for bstell

Status: VERIFIED INVALID

(Core :: Internationalization, defect)

Description

[kill this account]

make a font architecture where 3rd parties can plug in a font / rendering system 
to support other font types and/or languages such as Thai, Devenagri, etc

Comment 1

[kill this account]

want to be able to plugin Render support, Xft support, OpenType support

should support glyph subsitution and glyph positioning

Comment 2

[mjan]

Here are my whish list on this topic.

It would be great if there would be a "light" version of this architecture to 
begin with, which would only support font formats that are already supported by 
the OS. For example, TrueType, Type 1 and OpenType fonts formats are already 
supported on most Windows, Mac and Unix brands. There is no need to provide a 
rasterizer for these formats.

However, there is a need to allow the browser to use supported late font 
installations. Late font installation are fonts that have been made available 
on an OS *after* the browser started (e.g. was downloaded from a web site and 
temporarily installed for a web page).

A light version of this architecture would thus only provide support late font 
installs. Glyph shaping/positioning and rendering could be provided as a 
separate piece of code. To support late font installs, we need:

* Security; It must be possible to bind a late installed font to a web page or 
a web site, to prevent such font from being re-used without permissions. Some 
platforms (e.g. Windows and Mac) will also allow for temporarily installed 
fonts to only be available to specific processes as well. Both aspects must be 
fulfilled. 

* Synchronization browser<->plugin; A font plugin need a way to notify the 
browser that new fonts are available, and that a web page needs to be redone 
with these fonts. The browser would also need to notify the plugin that the 
fonts are no longer used when the page is closed.

All other aspects of the use of a font should go through the normal route 
through the rasterizer(s) on the platforms where Mozilla runs. There should 
thus not be any overhead in rendering the fonts.

With the current Netscape Plug-in interface, all we really need is a new NPP 
api that would let the browser know that a reflow of the document is needed.  

Comment 3

[Frank Tang]

give this to shanjian. Keep Future

Comment 4

[kill this account]

this was a reminder for bstell

Comment 5

[kill this account]

marking invalid

Comment 6

[Teruko Kobayashi]

Verified.

Comment 7

[kill this account]

Attachment: sample java applet