Closed Bug 463413 Opened 13 years ago Closed 10 years ago
Firefox does not form ligatures in fonts under 20 pixels
31.44 KB, text/html
148.58 KB, application/octet-stream
27.82 KB, application/octet-stream
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:18.104.22.168) Gecko/2008092417 Firefox/3.0.3 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:22.214.171.124) Gecko/2008092417 Firefox/3.0.3 (.NET CLR 3.5.30729) Ligature formation is fundamental to languages like Sinhala. The fact that ligatures are not formed under factory default settings in Firefox is a huge blow for all the affected communities without much technical background. Setting the browser.display.auto_quality_min_font_size to 0 by default would be fix for this problem. The change is minor however the benefit is beyond measure. Please fix this issue. Thanks. Reproducible: Always Steps to Reproduce: 1. (By default in about:config) see if browser.display.auto_quality_min_font_size is set to 20 2. Visit http://groups.google.com/group/SinhalaUserGroup/browse_thread/thread/b43a4f434c4f2f60 Actual Results: Ligatures are not formed. Expected Results: Proper ligature formation should be similar to http://img513.imageshack.us/img513/2574/ss20081106235248fj0.png Ligatures should form at every size, not only for larger sizes. browser.display.auto_quality_min_font_size is set to 0 fixes the problem. Some research into this shows me that it was set to 20 for performance issues. However, I have not experienced any performance hit.
Component: Preferences → Layout: Text
Product: Firefox → Core
QA Contact: preferences → layout.fonts-and-text
roc, do you remember how big the perf impact was when you decided on the 20pt cutoff in bug 387969? If it's substantial, would it be possible to turn it on only for languages or fonts that are known to require it?
I don't know what the impact is for Windows. I think we could localize the pref. Anyone with an LDAP account could test Tp via the tryservers. Note that another solution here is to set "text-rendering:optimizeLegibility" in the Web content, which will make us always use ligatures for that text.
I'd prefer not to use a localized pref; the language of the content need not correspond to the language of the UI.
This web page has Romanized Sinhala. The Romanized Sinhala text, which is in Latin characters, could also be viewed in native Sinhala script using an Open Type font (Suriyakumara.ttf) that has ligatures defined in it that defines complex forms of Sinhala base alphabetic letters and conjoint Sinhala letters. The page is virtually all ligatures. It is submitted for anyone to test it to VALIDATE or DEBUNK the idea that LIGATURES SLOW DOWN PAGE DISPLAY. The ligature forming is evoked using the SVG directive: "text-rendering: optimizeLegibility;" defined in its CSS file. The font is attached separately. Thanks. JC
This is a Sinhala smart font developed for Classic Sinhala. It is programmed to correctly render Pali and Sanskrit written in the Sinhala script. It has some 400 odd ligatures defined in it. Firefox does not display well-formed Sinhala letters until the size is increased to 20px or above. We believe that this decision is a mistake. Please test the attached web page with this font and observe that the page which is almost all ligatures does not display any slower than a regular Latin character page (as when the same page is displayed without the smart font in the system). Thank you. JC
Web based email (e.g. Yahoo) too has the same problem. The text has to be enlarged until the letters form.
Using a font to turn latin characters into Sinhala glyphs sounds pretty insane to me -- against the spirit of unicode on the web, like "symbol" fonts. Does the same problem with ligatures occur if you use actual Sinhala characters?
It is not an insane idea. Read more on SmartFonts. They are font rendering systems that have advanced typographic features such as choosing the proper glyph automatically. More info: http://en.wikipedia.org/wiki/Smartfont or http://en.wikipedia.org/wiki/OpenType These are actual Sinhala characters. As mentioned before, ligature formation is fundamental to Sinhala. Sinhala has over 400 ligatures which can be broken down and written in Latin letters. For example, similar to Serbian where "Nj" represents "Њ" in Cyrillic.
Comment #7: "turn latin characters into Sinhala glyphs sounds pretty insane to me". We are not asking if we are sane or not. No doubt that we who live in far away strange lands are kinked in our thinking. But we do not mean to harm Unicode or violate venerable intentions of Unicode. What would you say about German Fractur and Irish Celtic fonts (mentioned in Unicode 3 when discussing shapes v. characters)? http://www.library.yale.edu/cataloging/music/fraktur.htm http://www.ireland-information.com/freecelticfonts.htm Is there a geographic boundary for use of single-byte character set or is Latin-1 exclusively reserved for 14 Western European languages? This font tries to defeat the digital divide caused by Unicode Sinhala that is based on the 'sane' idea that Sinhala has an Abugida alphabet. Sinhala has no alphabet (a list of writing symbols). Instead, it has a phoneme chart called Hodiya that admits of clean interpretation in Latin letters. As an Asian, I do not know what is the spirit of Unicode other than it applies a crippling standard on us that we are expected to adhere to even though we do not know why. BDCS for us that stumbles everywhere and massacres our orthographies because of the Abugida approach even though demonstrably we can use SBCS. All we ask is equity. The question is simple: Is it true that there is a 'performance hit' caused by a font that has simple ligatures. If so, may we see the evidence? We gave a sample page which is a worse case specimen. Popularizing smart fonts for Romanized alphabets of Indic languages potentially brings millions of back-country Indic language users to the Firefox and Thunderbird user community and thereby to the modern cyber world. Please help us, as its time we get even handed treatment.
I am the person who designed this font. It fully complies with Unicode. However, I think we should not get carried away with the notion that Unicode rules. It is true that Unicode did not have good counsel from South Asians regarding their languages. 1990s was not a time when people form that part of the world were enlightened on IT. Mozilla works in the spirit of open and public cooperation of developers who wish well for the general humanity. My intention is similar. This font uses Basic Latin and Latin-1 code pages (ISO-8859-1). The rules that governed its design are given here: http://www.microsoft.com/typography/otfntdev/standot/appen.aspx I use the script tag "latin" and Language system tag "dflt". The font clothes Romanized Sinhala with the glyphs defined in it. The only OpenType feature Romanized Sinhala needs is "liga" that forms glyphs, which are so unlike the Latin letters. That is not prohibited anywhere. Adobe CS application suite supported my font since its release. SIL.org's Worldpad does so as well. Only Micrososft Office does not support it. Word does not support ligatures the font it introduced as its default font: Calibri. When asked why, the VOLT group manager said it is a business decision. Strangely, Vista's Notepad makes ligatures of Calibri and my fonts. The benefit this font brings to not-so-computer-savvy users like rural people without English education is tremendous. There are already hundreds of Thunderbird users because of this font. This bug report is an appeal by users of web based email among this group. I think the size limitation was done through the misunderstanding of scale of time used in table lookups in the font. I think SVG renders the letters in the nano-second scale and it uses GPU power to do it, not CPU. Sure, no speculation is better that testing the condition. Please test the page provided. You may also intersperse the web page with this most complex ligature it has: kxma to artificially load it up.
A web page using thousands of ligatures in Suriyakumara.ttf (31.44 KB, text/html) upload has some encoding issues. The zipped complete Web Page is directly saved from http://www.lovatasinhala.com/dualscript.htm
This bug has not been addressed. Is it abandoned?
IMO, as long as you're working against unicode and specifying fonts, you might as well specify "text-rendering: optimizeLegibility" too. But I'm still curious what the perf impact of setting browser.display.auto_quality_min_font_size to 0 would be (for English text).
Anyone who can push to the try-servers can find out! The current plan is to get Harfbuzz integrated and then remeasure. Then we'll try moving text shaping and measurement off the main thread and remeasure again on dual-core machines ... by then I think we'll be able to enable shaping everywhere at least for multicore users.
As one data point on Linux, the effect of disabling the fast shaping path was ~ 2-3% (bug 495455 comment 15). It _may_ be possible that not all of this difference is due to better shaping (bug 495455 comment 13). Also, setting browser.display.auto_quality_min_font_size to 0 could have a greater effect as that also enables better measuring of text bounds.
But that is an unfair comment, Jesse. Where is anything done *against* Unicode specifying fonts? Can you show me the violation? The way Unicode Sinhala is defined cannot support Pali or Sanskrit. Clearly, you have misunderstood the principle. Unicode 3.0 said on the first page of the web site that characters do not mean shapes of letters and cited Fraktur and Gaelic(?). That's what I went by. A clean and comprehensive transliteration was made and a font was made to accompany it. If it showed the traditional script flawlessly, then it is the complete solution for Sinhala, covering Pali and Sanskrit too. If you punish a group for using shapes for characters that are different from the traditional shapes because it provides them a comprehensive solution, along with it you are preventing fonts like Calibri and Zapfino on Firefox. Which is more important. Abide by some perceived convention or benefit to the users? On the technical side, it seems to me that we have not understood how ligatures are rendered. When the font sees a codepoint it *has* to go and retrieve the glyph. So, if it sees a codepoint that pairs with the previously typed letter, it fetches the glyph that combined them. The lookup work cannot be as time consuming as you think. Why we ask for this is because many people use web based email using Firefox. You'd change your mind and do the test if you see the light in their faces seeing the magic of the font. After all, English too was romanized in 600 AD why not Sinhala? Who stands to lose? If more people use transliterated languages more traditional software could be sold.
In Firefox trunk, we now do full shaping for all text on Windows (and Mac). We will do the same for Linux shortly. So this bug will be fixed soon.
This should now be fixed on trunk, as a result of bugs 449292 and 569770.
You need to log in before you can comment on or make changes to this bug.