Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||virtual font substitution mechanism|
|Status:||CLOSED DUPLICATE||QA Contact:||issues <issues.openoffice.org>|
|Priority:||P3||CC:||curvirgo, ikuya, issues, khirano, nesshof, tora3|
|Target Milestone:||OOo 2.0|
|Issue Type:||ENHANCEMENT||Latest Confirmation on:||---|
|Issue Depends on:||20370|
Description maho.nakata 2003-06-14 01:46:25 UTC
Currnt font substition mechanism is very insufficient when one wants do desktop publishing, in professional quality. and OOo is not attractive especially Mac users who have been doing DTP as a professional job. 1. Layout of writer documents, impress presentation depends on the device (for example, printer) and platform (Windows or Linux; UNIX). I heard that MS Office has simular problems. You may know that output of PostScript and TeX are independent from device (well strictly saying this is wrong but they try to do) Output of TeX is dvi. Dvi is abbreviation of DeVice Independent. Format of fonts are quite smart. They typeset with afm (adobe font metrics) or tfm (TeX font metrics) and they contain only the infomation about ligature, kerning, and so on; namely they have the relationship between letter and letter. Note: afm files of some fonts are usually freely obtainable, and I know there are afm files in the OOo source. I also like to note that there are same fonts with different resolution, 600 dpi or 2400 dpi (you can imagine which costs higher). And for personal use, 600 dpi is sufficient. 2. Some people may want to use PostScript fonts. Avant Garde, Times, Helvetica, Times, Courier and Palatino... many people used these fonts very frequently. Fortunately, we can obtain (GPL'ed) URW fonts; high qualty and almost compatible with corresponding Adobe's fonts. Sander feels anxiety about GPL but it can be avoidable, just not embedding these fonts when exports. Each person has URW fonts so there are no problem for on the screen. Thronade, which is also high quality font came with OOo and SO/SS, but many people still want to use PostScript fonts. Things will be more complicated between Windows/UNIX. OOo is platform independent, and layout of documets should also be platform independent, however, fonts are platform dependent even between SS/SO and OOo. So layout of documents using OOo with Windows or Linux will strictly saying, different and sometimes it is a very critical problem. 3. License probelm can be solved by subsituting the name of the font. We don't necessary to embed URW fonts to PDF. Just tell the name of the Adobe's fonts and Acrobat reader understand the name of the fonts and automatically use, say, Times roman and Avant Garde. 4. For Asian, espcially Chinese, Japanese and Korean, getting high quality and free fonts are very difficult. Because there are over 10,000 characters for each fonts. For example, we Japanese use Ryumin-Light and Gothic-BBB as a two standard fonts for DTP. Not MS-mincho/Gothic came with Windows. We can still obtain afm files freely (for other important fonts, too). Standard fonts for OOo/SS/SO are urgently needed, although it is possible to use non-standard GPL'ed fonts, but it is apparently not a good situation (do not become a standard since quality or political reasons). For StarOffice, SUN provides Japanese fonts, which is non-free one. So we will soon encounter incompatibility between OOo, SS and SO. Programs shares nearly same source code, but there are strict imcompatibilty. Very sad. g afm or something like that. and use them with substitution to URW fonts on the screen, but do not embed to PDF. I think this is the best solution. This solves: 1. Platform dependency and device dependency. 2. License problem. 3. Rich and poor man can typeset with the same layout. If you want high quality or real fonts, just buy. Publisher may have such fonts, so poor man's can do nealy the same job with definetely same layout. 4. We can have better feature than MS Office!
Comment 1 maho.nakata 2003-06-14 03:36:33 UTC
Created attachment 6864 [details] patch for sal/osl/unx/system.h
Comment 2 christof.pintaske 2003-06-16 09:12:38 UTC
cp->ama: looks like an rfe. please comment on 1 and eventually pass on to falko 1. looks like a rfe mainly about printer independent rendering. I think that's something writer already provides ? 2. I don't think it's a good idea to ship the URW fonts again and again. We are going for more system integration in future and will try to use the systems font configuration to deal with this problem. 3. We already do not embedd the standard pdf fonts 4. We use ttf fonts for CJK. I can't really see what afm might help if you simply cannot see a single char in your document. I have no clue what the attachment is for
Comment 3 andreas.martens 2003-09-10 15:47:08 UTC
We have the printer independent layout but we'll always have a font dependent layout. If you open a document (under different platforms) and you don't have the same fonts (font metrics) you'll get a different layout. If you use printer independent layout, the fonts are available and you get a different layout then it's a bug. I'm not aware of plans to store fonts or font metrics within the documents or plans for shipping URW fonts etc.
Comment 4 maho.nakata 2003-10-08 10:09:59 UTC
Thanks for showing interest for my issue. I'm considering the font problem, when we face cross platfrom use. for example, Windows users, which have large share, may use fonts come with Windows. However, for Linux, different fonts are supplied, sometimes diffrent fonts have same names. In this case, layout of documents are changed. I think this is the major problem. StatSuite/StarOffice have their own fonts, in this case problem is even more serious...since no way to obtain fonts other than buying StarSuite/StarOffice. it is very sad situation. In Japanese, each fonts has over 10000 characters, and high quality de facto standard fonts are of course proprietary, and they cost extremely high, however, usually AFMs are supplied. So poor-man's solutions can be made, typesetting with AFM, and substitution to other cheap fonts. TeX can be used cross platform, Windows, Linux, Mac OS... since they have own metrics files.
Comment 5 falko.tesch 2003-10-15 10:51:25 UTC
FT->AMA: We actually DO have plans to embed fonts in OO.o documents. Please contact GÃ¶tz Wohlberg in this matter. He is the owner of this feature request. Thx.
Comment 6 maho.nakata 2003-10-22 02:55:04 UTC
Thanks, please make some ways to treat afm or tfm files...this is *really* good virtual scheme. namely do not contain glyphs. there are many tfm from TeX and afm from PostScript... they preserve metrics, so professional cross platform use can be realized... --maho
Comment 7 maho.nakata 2003-10-22 03:39:17 UTC
as far as I know, some afms are already included in OOo. psprint_config/configuration/afm/GothicBBB-Medium-83pv-RKSJ-H.afm psprint_config/configuration/afm/GothicBBB-Medium.Roman.afm psprint_config/configuration/afm/Helvetica-Bold.afm psprint_config/configuration/afm/Helvetica-BoldOblique.afm psprint_config/configuration/afm/Helvetica-Oblique.afm psprint_config/configuration/afm/Helvetica.afm psprint_config/configuration/afm/NewBaskerville-Bold.afm psprint_config/configuration/afm/NewBaskerville-BoldItalic.afm psprint_config/configuration/afm/NewBaskerville-Italic.afm psprint_config/configuration/afm/NewBaskerville-Roman.afm psprint_config/configuration/afm/NewCenturySchlbk-Bold.afm psprint_config/configuration/afm/NewCenturySchlbk-BoldItalic.afm psprint_config/configuration/afm/NewCenturySchlbk-Italic.afm psprint_config/configuration/afm/NewCenturySchlbk-Roman.afm psprint_config/configuration/afm/Palatino-Bold.afm psprint_config/configuration/afm/Palatino-BoldItalic.afm psprint_config/configuration/afm/Palatino-Italic.afm psprint_config/configuration/afm/Palatino-Roman.afm psprint_config/configuration/afm/Ryumin-Light-83pv-RKSJ-H.afm psprint_config/configuration/afm/Ryumin-Light.Roman.afm psprint_config/configuration/afm/Symbol.afm psprint_config/configuration/afm/Times-Bold.afm psprint_config/configuration/afm/Times-BoldItalic.afm psprint_config/configuration/afm/Times-Italic.afm psprint_config/configuration/afm/Times-Roman.afm psprint_config/configuration/afm/Windsor.afm psprint_config/configuration/afm/ZapfChancery-MediumItalic.afm psprint_config/configuration/afm/ZapfDingbats.afm suprisingly, Ryumin-Light-83pv-RKSJ-H.afm and GothicBBB-Medium-83pv-RKSJ-H.afm are Japanese fonts!
Comment 8 ikuya 2003-10-22 11:50:17 UTC
I'm second to maho. We summarize over 50 templates for Presntation (and other stuffs) for Japanese users at http://desktop.good-day.net/ooo11/ (for Linux) and http://oooug.jp/1.1/katsuyou/ (for Windows) Of course, de facto standard fonts for puhlishers/Windows are proprietary. For example, professional publishers prefer Ryumin and Gothic-BBB, Windows user use MS Mincho and MS Gothic while Linux use Kochi-mincho, and Kochi-gothic, metrics of Ryumin/MS Mincho/Kochi-Mincho employ are different. So layouts are always subected to change. We are maintaining two different templates for each platform (Windows/Linux) with large efforts. Apparently, this is just a nightmare.
Comment 9 andreas.martens 2003-11-04 16:35:33 UTC
Anything planned for embedded fonts?
Comment 10 maho.nakata 2003-11-04 16:57:03 UTC
Apparently, embidding fonts cannot solve this issue. Would you please explain this more in detail? I thought that you mean embed font data in every document, then how about some glyphs in a font set which are not embidded? For Japanese, one font set contain 10,000 chars, and other lang might have such kind of problem, too.
Comment 11 goetz.wohlberg 2003-11-17 13:48:57 UTC
GW->CP: This is also in your arena.
Comment 12 christof.pintaske 2003-12-04 15:26:16 UTC
Comment 13 christof.pintaske 2004-02-16 13:49:10 UTC
I'd like to handle this issue in #i20370#. Both reports have some overlap and are partly mutual exclusive. So this issue cannot be discussed isolated. Please join in 20370 *** This issue has been marked as a duplicate of 20370 ***
Comment 14 christof.pintaske 2004-02-20 16:45:45 UTC
closing this one in favour of i20370