Issue 15611

Summary:

virtual font substitution mechanism

Product:

gsl

Reporter:

maho.nakata

Component:

code

Assignee:

christof.pintaske

Status:

CLOSED DUPLICATE

QA Contact:

issues@gsl <issues>

Severity:

Trivial

Priority:

CC:

curvirgo, ikuya, issues, khirano, nesshof, tora3

Version:

current

Target Milestone:

OOo 2.0

Hardware:

Other

OS:

Other OS

Issue Type:

ENHANCEMENT

Latest Confirmation in:

---

Developer Difficulty:

---

Issue Depends on:

20370

Issue Blocks:

Attachments:

Description	Flags
patch for sal/osl/unx/system.h	none

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

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