Issue 15611 - virtual font substitution mechanism
Summary: virtual font substitution mechanism
Status: CLOSED DUPLICATE of issue 20370
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: current
Hardware: Other Other OS
: P3 Trivial (vote)
Target Milestone: OOo 2.0
Assignee: christof.pintaske
QA Contact: issues@gsl
Depends on: 20370
  Show dependency tree
Reported: 2003-06-14 01:46 UTC by maho.nakata
Modified: 2004-02-20 16:45 UTC (History)
6 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

patch for sal/osl/unx/system.h (1.87 KB, patch)
2003-06-14 03:36 UTC, maho.nakata
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
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
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...


Comment 7 maho.nakata 2003-10-22 03:39:17 UTC
as far as I know, some afms are already included in OOo.

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 (for Linux)
and (for Windows)
Of course, de facto standard fonts for puhlishers/Windows are
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
target adjusted
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