Hi All,
I am going to release lohit-Devanagari today, presently we have Marathi, Hindi, Nepali, Maitreya, kashmiri (Dev), Sindhi (Dev) Devanagari script base fonts, and all are same, there was plan to add/modify respective font as per each language requirement but having a super set is no problem and we are following that presently But somehow while discussing more on it, i found it we can use only Devanagari font for all without affecting any language other requirement, and also it will be better for development and maintenance as well. In future if we found that two language with same script, requires different representation of same characters either we can use <LANG> tag of Open Type or We can split font that time as per requirement so to the best of my knowledge there is no problem in using same Devanagari script covering all Unicode characters for all languages using Devanagari script. comment/suggestions are welcome
Thanks, Pravin S
2010/1/29 प्रविण सातपुते pravin.d.s@gmail.com
Hi All,
I am going to release lohit-Devanagari today, presently we have Marathi, Hindi, Nepali, Maitreya, kashmiri (Dev),Sindhi (Dev) Devanagari script base fonts, and all are same, there was plan to add/modify respective font as per each language requirement but having a super set is no problem and we are following that presently But somehow while discussing more on it, i found it we can use only Devanagari font for all without affecting any language other requirement, and also it will be better for development and maintenance as well. In future if we found that two language with same script, requires different representation of same characters either we can use <LANG> tag of Open Type or We can split font that time as per requirement so to the best of my knowledge there is no problem in using same Devanagari script covering all Unicode characters for all languages using Devanagari script. comment/suggestions are welcome
Before doing that, would you please check if <LANG> tag can be successfully used to distinguish between Marathi and Hindi 'La (ल)', Marathi and Hindi digit '8' on Gnome/KDE. Similarly there would be variations for some Nepali and Kashmiri characters. If possible this would also help solving problems related to traditional and typewriter script of Malayalam.
2010/1/30 Rahul Bhalerao b.rahul.pm@gmail.com
2010/1/29 प्रविण सातपुते pravin.d.s@gmail.com
Hi All,
I am going to release lohit-Devanagari today, presently we have Marathi, Hindi, Nepali, Maitreya, kashmiri (Dev),Sindhi (Dev) Devanagari script base fonts, and all are same, there was plan to add/modify respective font as per each language requirement but having a super set is no problem and we are following that presently But somehow while discussing more on it, i found it we can use only Devanagari font for all without affecting any language other requirement, and also it will be better for development and maintenance as well. In future if we found that two language with same script, requires different representation of same characters either we can use <LANG> tag of Open Type or We can split font that time as per requirement so to the best of my knowledge there is no problem in using same Devanagari script covering all Unicode characters for all languages using Devanagari script. comment/suggestions are welcome
Before doing that, would you please check if <LANG> tag can be successfully used to distinguish between Marathi and Hindi 'La (ल)', Marathi and Hindi digit '8' on Gnome/KDE. Similarly there would be variations for some Nepali and Kashmiri characters. If possible this would also help solving problems related to traditional and typewriter script of Malayalam.
need to test these things but presently there is no harm in going with lohit-devanagari since all its variant are same but yeah in future development we need to do this. we will try this things soon need to see which rendering engine presently support it may be it will be helpful pointer in development of harfbuzz as well
Best Regards, Pravin S
प्रविण सातपुते wrote:
2010/1/30 Rahul Bhalerao b.rahul.pm@gmail.com
2010/1/29 प्रविण सातपुते pravin.d.s@gmail.com
Hi All,
I am going to release lohit-Devanagari today, presently we have Marathi, Hindi, Nepali, Maitreya, kashmiri (Dev),Sindhi (Dev) Devanagari script base fonts, and all are same, there was plan to add/modify respective font as per each language requirement but having a super set is no problem and we are following that presently But somehow while discussing more on it, i found it we can use only Devanagari font for all without affecting any language other requirement, and also it will be better for development and maintenance as well. In future if we found that two language with same script, requires different representation of same characters either we can use <LANG> tag of Open Type or We can split font that time as per requirement so to the best of my knowledge there is no problem in using same Devanagari script covering all Unicode characters for all languages using Devanagari script. comment/suggestions are welcome
Before doing that, would you please check if <LANG> tag can be successfully used to distinguish between Marathi and Hindi 'La (ल)', Marathi and Hindi digit '8' on Gnome/KDE. Similarly there would be variations for some Nepali and Kashmiri characters. If possible this would also help solving problems related to traditional and typewriter script of Malayalam.
need to test these things but presently there is no harm in going with lohit-devanagari since all its variant are same but yeah in future development we need to do this. we will try this things soon need to see which rendering engine presently support it may be it will be helpful pointer in development of harfbuzz as well
Instead of releasing single font files for all those languages which use the same script in slightly different variations, you could release a single .ttc file which includes all those fonts, but saves space, since most of the glyphs are the same in all those languages.
If you need help on how to do this, ask me.
Language codes are possible, but most software cannot deal with that.
Cheers Arne
2010/2/3 "Arne Götje (高盛華)" arne@linux.org.tw
Instead of releasing single font files for all those languages which use the same script in slightly different variations, you could release a single .ttc file which includes all those fonts, but saves space, since most of the glyphs are the same in all those languages.
looks interesting, i have made some apple font suites long time back but not done anything w.r.t. ttc (dont know is it same ;))
If you need help on how to do this, ask me.
need to test it once before adding in tree, your help is welcome :) Does fontforge support it? It will be if you can give one example of this
Language codes are possible, but most software cannot deal with that.
That is the problem, but i think it will happen soon <LANG> tag have so much importance in language sharing same script, like Arabic code page support more than 6 lang. and some characters have different variations as per language
Thanks, Pravin S
Le Mer 3 février 2010 01:15, "Arne Götje (高盛華)" a écrit :
प्रविण सातपुते wrote:
Instead of releasing single font files for all those languages which use the same script in slightly different variations, you could release a single .ttc file which includes all those fonts, but saves space, since most of the glyphs are the same in all those languages.
If you need help on how to do this, ask me.
Please don't create more TTC fonts unless absolutely necessary. Multiple different font faces and families in the same file badly break many application expectations. The file size wins are not worth it. locl on the other hand is well supported as it's the standard way to handle cyrillic and turkish
Nicolas Mailhot wrote:
Le Mer 3 février 2010 01:15, "Arne Götje (高盛華)" a écrit :
प्रविण सातपुते wrote:
Instead of releasing single font files for all those languages which use the same script in slightly different variations, you could release a single .ttc file which includes all those fonts, but saves space, since most of the glyphs are the same in all those languages.
If you need help on how to do this, ask me.
Please don't create more TTC fonts unless absolutely necessary. Multiple different font faces and families in the same file badly break many application expectations. The file size wins are not worth it. locl on the other hand is well supported as it's the standard way to handle cyrillic and turkish
We are not talking about *different font faces and families in the same .ttc. *That* should not be done, I agree. We are talking about the *same* font face and family where 90+% of all glyphs are the same and only few differ by language code.
Regarding the 'locl' feature: It may work well in up-to-date software, but it surely doesn't work in older installations. So, providing both ways would probably best. I.e. give the user two choices: use the font with the 'locl' feature first and if that doesn't work for you, then try the .ttc approach.
Cheers Arne
Le mercredi 03 février 2010 à 08:56 -0800, "Arne Götje (高盛華)" a écrit :
Regarding the 'locl' feature: It may work well in up-to-date software, but it surely doesn't work in older installations.
Sadly almost every single smart font feature won't work in older installations. There is no way to support those without giving up on all the bits that have been added to the OpenType spec for i18n. And at that point, making people switch to a text stack that understands Opentype is a lot less work than trying to accomodate complex i18n cases without the features added to the spec to help doing so. (Unfortunately, too few OpenType features are used in English for the average English-speaking app writer to care about them. So they keep finding reasons not to use "complex" text stacks)
Now, I realize all Opentype features are not equal, some are almost never used and could be considered exotic, but this is not the case for locl. IIRC it's the default way according to MS to support Turkish and Balkanic/Russian Cyrillic. Those are not considered complex or minority scripts, coverage is expected of new latin or cyrillic fonts.
I'd be very surprised if more app designers had heard of ttc than of locl. TTC is *very* uncommon in comparison to fonts that use locl. I'd expect both to break in old (or even recent apps), but ttc support to break more.
But anyway, as long as the "one font family and face per font file" property that every font format but TTC guarantees is preserved, I don't personally object to ttc use. Just have doubts it will work out any better than locl.
On 2/3/2010 4:42 PM, Nicolas Mailhot wrote:
I'd be very surprised if more app designers had heard of ttc than of locl. TTC is *very* uncommon in comparison to fonts that use locl. I'd expect both to break in old (or even recent apps), but ttc support to break more.
It is strange, your experience seems to be very different from mine.
IMHO, TTC support across most platforms is quite old and reliable in the past. Many of the CJK fonts on Windows were shipped in the TTC forms since Win95 age, and are still used today; freetype2 also supports ttc from early ages. For WQY fonts, I have never had any issue with TTC format for PC users. The only places where it seem to break are cell phones running WM or Symbian OS.
It is true that it is uncommon for non-latin fonts (because it gains little benefit), but that's different from it is unreliable. It is rather a simple format as it only merges the identical tables.
Thanks to freetype2 and fontconfig, the ttc format is almost transparent to applications, unless they want to deal with the font file itself.
But anyway, as long as the "one font family and face per font file" property that every font format but TTC guarantees is preserved, I don't personally object to ttc use. Just have doubts it will work out any better than locl.
Even the "one font family per file" is not entirely necessary. For example, WQY Zenhei TTC contains 3 fonts, Zen Hei (sans), Zen Hei Mono (mono) and Zen Hei Sharp (same as Zen Hei but with embedded bitmaps). All three fonts share the same glyf table. For the sans and mono faces,only the cmap tables are different. This literately cut down the font file to 1/3 of 3 TTF.
I would encourage using TTC whenever it is possible. The format seems to be well supported and quite reliable to me.
Le Jeu 4 février 2010 00:12, Qianqian Fang a écrit :
On 2/3/2010 4:42 PM, Nicolas Mailhot wrote:
I'd be very surprised if more app designers had heard of ttc than of locl. TTC is *very* uncommon in comparison to fonts that use locl. I'd expect both to break in old (or even recent apps), but ttc support to break more.
It is strange, your experience seems to be very different from mine.
Not at all. I should have said 'TTC is almost unknown of except for CJK users'. So it will work for CJK-oriented apps, and behave strangely elsewhere.
(The way some CJK fonts only export a CJK non-latin name is very disturbing to many apps too. Lots of fun for CSS rules too. CJK users do not see it because they only use an environment that targets CJK users with CJK defaults).
Nicolas Mailhot wrote:
Not at all. I should have said 'TTC is almost unknown of except for CJK users'. So it will work for CJK-oriented apps, and behave strangely elsewhere.
It was the "behave strangely" bit that I disagreed. I think they behave flawlessly in most case, despite they are uncommon for non CJK fonts.
(The way some CJK fonts only export a CJK non-latin name is very disturbing to many apps too. Lots of fun for CSS rules too. CJK users do not see it because they only use an environment that targets CJK users with CJK defaults).
To my knowledge, this is not that common. The only oddities I know are SimSun/SimHei (the default Chinese fonts for Win9x,Win2x) which contain a non-Latin PS font name; but their TTF name table have names for both Chinese and English.
Le Jeu 4 février 2010 16:54, Qianqian Fang a écrit :
To my knowledge, this is not that common. The only oddities I know are SimSun/SimHei (the default Chinese fonts for Win9x,Win2x) which contain a non-Latin PS font name; but their TTF name table have names for both Chinese and English.
However, modern software reads the OpenType name, so having a latin name in one of the older layers is of little use (most win32 apps do not read the OpenType name yet but that's not the case under Linux)
To follow up, just for comparison:
-rw-r--r-- 1 arne arne 109008 2010-02-02 16:44 Lohit-Devanagari.ttc -rw-r--r-- 1 arne arne 81484 2010-02-02 16:23 lohit_hi.ttf -rw-r--r-- 1 arne arne 81228 2010-02-02 16:23 lohit_kok.ttf -rw-r--r-- 1 arne arne 81240 2010-02-02 16:23 lohit_ks.ttf -rw-r--r-- 1 arne arne 81256 2010-02-02 16:23 lohit_mai.ttf -rw-r--r-- 1 arne arne 81228 2010-02-02 16:23 lohit_mr.ttf -rw-r--r-- 1 arne arne 81216 2010-02-02 16:23 lohit_ne.ttf -rw-r--r-- 1 arne arne 81216 2010-02-02 16:23 lohit_sd.ttf
While each .ttf is 81kb, the .ttc I have produced is only 109kb and includes all the single fonts. Internally, the glyphs which are the same, are shared.
Cheers Arne
-
"Arne Götje (高盛華)" -
Nicolas Mailhot -
pravin.d.s＠gmail.com -
Qianqian Fang -
Rahul Bhalerao