158129 - Add support for Adobe's Type1 Euro fonts

Status: RESOLVED WONTFIX

(Core :: Graphics: Text, defect)

Description

[Roland Mainz]

[Per
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&th=5a8c34a30ab5662a&rnum=1]
Adobe ships a set of one-glyph PS Type1 euro symbol fonts, see
ftp://ftp.adobe.com/pub/adobe/type/win/all/

It would be nice if we could support these fonts to get cheap&simple euro
support on Linux.

Comment 1

[Roland Mainz]

Attachment: Euro font repackaged as tar.gz, incl. fonts.scale, fonts.dir and PSres.upr to make all Xservers happy

Comment 2

[Roland Mainz]

Attachment: Screenshot of xfd viewing '-adobe-eurosans-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific'

Comment 3

[Roland Mainz]

Assigning to shanjian...

Comment 4

[Shanjian Li]

Roland, euro symbol displayed fine on Linux, why we want to support such a hack?

Comment 5

[Wesha]

--> enhancement?

Comment 6

[Roland Mainz]

Shanjian Li wwrote:
> euro symbol displayed fine on Linux, why we want to support such a hack?

Actually the euro symbol support in Mozilla only works if ISO8859-15 (or
ISO10646-1) fonts are present. ISO8859-15 differs from ISO8859-1 (AFAIK) only in
the detail that the euro symbol replaced another (currency?) symbol ('¤'),
therefore this font would add Euro-support on those platforms without the need
to get other glyphs from those (somtimes very ugly) bitmap ISO8859-15 fonts (I
always wondered why pages in the ISO8859-15 encoding looks far worse than the
same HTML page in ISO8859-1 encoding - looks I found the root of all evil... ;-(
).
The Euro currency symbol has exactly one shape, therefore it should "fit"
correctly into all existing font families (this is just another vendor-specific
symbol font - like the Mathematica stuff, too).

Comment 7

[jag (Peter Annema)]

Erh... I think this is a bad idea.

Comment 8

[Roland Mainz]

Peter Annema wrote:
> Erh... I think this is a bad idea.

I do not think it is bad.
Adobe created this font exactly for the purpose to get Euro-support for their
products.

Why can't we do the same (otherwise we end-up in the problem that we have either
non-existing euro-support or euro-support which looks bad...) ?

Comment 9

[jag (Peter Annema)]

I misunderstood Roland. This idea seems better now, though it'll only benefit
those people who have this font installed. As Roland pointed out, we could put
this in release notes, and someone (else) can lobby with Linux distributors to
ship this.

Comment 10

[Roland Mainz]

AFAIK we can implement this the same way as the support for the adobe symbol
fonts...

Comment 11

[kill this account]

Roland: are you proposing to use mozilla as a distribution system for X fonts?

Comment 12

[Roland Mainz]

bstell wrote:
> are you proposing to use mozilla as a distribution system for X fonts?

Heh... jag had the same question.
No, I am looking to fight the problem that our Euro-support is pretty worse on
older systems - pages with ISO8859-1 are OK, but pages with ISO8859-15 encoding
look pretty worse.
I wonder why we can't fix the problem by providing the "euro" symbol with the
special "euro"-symbol font and then treat every ISO8859-1 font as ISO8859-15
font (and replace char #80 (ISO8859-15 entry for the euro-symbol) with the
matching glphy from either a real ISO8859-15 font or adobe's special euro symbol
font).

Applix did that for their products, Adobe did that for their products - why
can't we do the same, too ?

Comment 13

[kill this account]

> Heh... jag had the same question.

Clearly it is an important question, :)

> I wonder why we can't fix the problem by providing the "euro" symbol with the
> special "euro"-symbol font and then treat every ISO8859-1 font as ISO8859-15
> font (and replace char #80 (ISO8859-15 entry for the euro-symbol) with the 
> matching glphy from either a real ISO8859-15 font or adobe's special euro 
> symbol font).

Good idea. Moz already tries to do use the -15 euro symbol so adding the
adobe font would be a good addition.

http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#4542
4542       // before we put in the transliterator to disable double byte special 
chars
4543       // add the x-western font before the early transliterator
4544       // to get the EURO sign (hack)

Were you thinking of adding the here or did you have a more agressive plan?

Comment 14

[Roland Mainz]

Brian Stell wrote:
> http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#4542
> 4542       // before we put in the transliterator to disable double byte 
> special  chars
> 4543       // add the x-western font before the early transliterator
> 4544       // to get the EURO sign (hack)
> 
> Were you thinking of adding the here or did you have a more agressive plan?

It looks sufficient for me to put it "in" here, but a more agressive plan can't
hurt (the EURO-symbol has exactly one standardised shape and Adobe's euro symbol
font is scaleable, therefore we can't do much wrong here... :)

Maybe we can use the upcoming patch for the adobe euro sybol font as "blueprint"
for the other symbol fonts we do not support yet (like "*-dtsymbol-1",
"sunolglyph-1", "dec-dectech" etc. (I do not say we want to implement them all,
but having blueprints for adding support would be nice :))

Comment 15

[kill this account]

> the EURO-symbol has exactly one standardised shape 

I am for this but I do want to point out that we still risk the "ransom note" 
effect. The glyph still might not match the font design; eg: relative to the
primary font this glyph might be too light/bold, slanted, tall, wide/narrow, ... 

> and Adobe's euro symbol font is scaleable, 

What scaling technology? Without anti-aliased scaling even outline fonts tend
to look poor.

Comment 16

[Roland Mainz]

Brian Stell wrote:
> > the EURO-symbol has exactly one standardised shape 
>
> I am for this but I do want to point out that we still risk the "ransom note" 
> effect. The glyph still might not match the font design; eg: relative to the
> primary font this glyph might be too light/bold, slanted, tall, wide/narrow, 
> ...

AFAIK we will only look at other fonts (like adobe's euro symbol font) if the
"current" font doesn't have it, right ?
Taking glyphs from other fonts isn't always perfect - but adobes euro symbol
font package comes with some variations which should cover the common cases.

> > and Adobe's euro symbol font is scaleable, 
>
> What scaling technology? Without anti-aliased scaling even outline fonts tend
> to look poor.

OKOK, but it's still better to see the euro symbol instead of '?' ... =:-)
Having matching euro fonts is better, but we need support for older
environments, too. You can't tell companies/banks to upgrade to the
latest/greatest OS version just to get the euro symbol in mozilla when all other
applications have euro support with their current installation base.

Comment 17

[jag (Peter Annema)]

"just to get the euro symbol in mozilla when all other applications have euro
support with their current installation base."

So far you've named Applix and Adobe. When did that become "_all other_
applications"?

Comment 18

[kill this account]

in general this seems like a good thing to do

Comment 19

[Roland Mainz]

bstell/shanjian:
Does support for '-adobe-eurosans-*-adobe-fontspecific'-fonts require anything
else beyond the following two things:
1. A encoder in intl/uconv/ucvlatin/ (e.g.
intl/uconv/ucvlatin/nsUnicodeToAdobeEuro.cpp)
  and
2. entries in +nsFontMetricsGTK.cpp/nsFontMetricsXlib.cpp

That's all, right ?

Comment 20

[Shanjian Li]

That's the major things in my mind too. But I have no idea if they are complete
or not. Mark it as assigned, but I won't have time for this bug in near future.
Feel free to take it. 

Comment 21

[Roland Mainz]

Shanjian Li wrote:
> That's the major things in my mind too. But I have no idea if they are 
> complete or not.

bstell?

> Mark it as assigned, but I won't have time for this bug in near future.
> Feel free to take it. 

I can take it if someone can say if the list in comment #19 is complete or not
(and if the answer is "no" I need the missing pieces of the puzzle...) ...

Comment 22

[kill this account]

what is the encoding of '-adobe-eurosans-*-adobe-fontspecific'?

I think you have to add an entry here:

408 static nsFontCharSetMap gCharSetMap[] =
409 {
410   { "-ascii",             &FLG_NONE,    &Unknown       },
411   { "-ibm pc",            &FLG_NONE,    &Unknown       },
412   { "adobe-fontspecific", &FLG_NONE,    &Special       },

and here:

546 static nsFontCharSetMap gSpecialCharSetMap[] =
547 {
548   { "symbol-adobe-fontspecific", &FLG_NONE, &AdobeSymbol  },

and a converter

Comment 23

[Roland Mainz]

Brian Stell wrote:
> what is the encoding of '-adobe-eurosans-*-adobe-fontspecific'?

It looks that position 0x80 has the Euro sign (and some other places, too (for
an unknown reason)) - that's all we need... :)

> I think you have to add an entry here:
> 408 static nsFontCharSetMap gCharSetMap[] =
[snip]
> and here:
> 546 static nsFontCharSetMap gSpecialCharSetMap[] =
[snip]
> and a converter

Thanks!

Comment 24

[Roland Mainz]

Next question:
Where can I get the tool from to generate the *.uf mapping file (e.g. something
like mozilla/intl/uconv/ucvlatin/adobesymbol.uf) ?

Comment 25

[kill this account]

Check with ftang, he had conversion scripts but I cannot remember where they
are.

Comment 26

[Roland Mainz]

Attachment: Testcase

Comment 27

[Roland Mainz]

Taking myself...

Comment 28

[Roland Mainz]

Attachment: Prototype patch for 2002-09-18-08-trunk

Comment 29

[Roland Mainz]

ToDo:
- Figure-out why the patch doesn't work without the following hack:
-- snip --
       nsCAutoString ffre("*-symbol-adobe-fontspecific");
       nsFontGTK* symbol_font = TryNodes(ffre, 0x0030);
 
+      // Add the Adobe Euro fonts before the early transliterator
+      nsCAutoString euro_ffre("*-euro*-adobe-fontspecific");
+      nsFontGTK* euro_font = TryNodes(euro_ffre, 0x20AC);
+
       // add the early transliterator
       // to avoid getting Japanese "special chars" such as smart
       // since they are very oversized compared to western fonts
@@ -4623,6 +4633,9 @@
       else if (symbol_font && CCMAP_HAS_CHAR(symbol_font->mCCMap, aChar)) {
         return symbol_font;
       }
+      else if (euro_font && CCMAP_HAS_CHAR(euro_font->mCCMap, aChar)) {
+        return euro_font;
+      }
-- snip --

Comment 30

[Roland Mainz]

shanjian/bstell:
Any ideas about the problem described in comment #29 ?

Comment 31

[kill this account]

Probably because its one of the chars that gets transliterated. 

http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#613

613 // smart quotes (and other special chars) in Asian (double byte)
614 // fonts are too large to use is western fonts.
615 // Here we define those characters.
616 //
617 static PRUnichar gDoubleByteSpecialChars[] = {
618   0x0152, 0x0153, 0x0160, 0x0161, 0x0178, 0x017D, 0x017E, 0x0192,
619   0x02C6, 0x02DC, 0x2013, 0x2014, 0x2018, 0x2019, 0x201A, 0x201C,
620   0x201D, 0x201E, 0x2020, 0x2021, 0x2022, 0x2026, 0x2030, 0x2039,
621   0x203A, 0x20AC, 0x2122,
622   0
623 };

Until someone decides to spend the time to rework when the tranliteration happens
(not a huge job but not small either) the code in comment 29 is correct and 
needed.

Comment 32

[Roland Mainz]

Brian Stell wrote:
> Probably because its one of the chars that gets transliterated. 
> http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#613
> 613 // smart quotes (and other special chars) in Asian (double byte)
> 614 // fonts are too large to use is western fonts.
> 615 // Here we define those characters.
> 616 //
> 617 static PRUnichar gDoubleByteSpecialChars[] = {
[snip]
621   0x203A, 0x20AC, 0x2122,

OK, I am blind...

Thanks for the hint... :)

> Until someone decides to spend the time to rework when the tranliteration 
> happens (not a huge job but not small either) the code in comment 29 is 
> correct and needed.

Is there a bug for that yet ?

Comment 33

[Roland Mainz]

Attachment: New patch for 2002-09-23-08-trunk

Updated patch with minor cleanup and some comments to make the code little bit
easier to read...

Comment 34

[Roland Mainz]

Requesting r=/sr= ...

Comment 35

[kill this account]

> Is there a bug for that yet ?

I don't think so.

Comment 36

[kill this account]

Comment on attachment 100734 [details] [diff] [review]
New patch for 2002-09-23-08-trunk

r=[e-mail]

Comment 37

[Roland Mainz]

Brian Stell wrote:
> > > Until someone decides to spend the time to rework when the tranliteration 
> > > happens (not a huge job but not small either) the code in comment 29 is 
> > > correct and needed.
> >
> > Is there a bug for that yet ?
>
> I don't think so.

Can you file it, please (and assign it to me) ? IMHO you can describe the issue 
far better than I can do... :)

Comment 38

[Roland Mainz]

bstell:
If I remove the entry for the EURO-sybol in |gDoubleByteSpecialChars| the char
doesn't get transliterated (on a system where I don't have any iso8859-15 fonts
installed - I would expect that |FindSubstituteFont()| would kick in here - but
instead |FindStyleSheetGenericFont()| returns a font which does not contain the
EURO symbol - I get a blank displayed instead (e.g. no '?' or "EUR") ... ;-( ).
Do you have any idea why this happens ?

Comment 39

[kill this account]

Does the encoder for the font think it has a glyph for the euro char?

Comment 40

[Roland Mainz]

Brian Stell wrote:
> Does the encoder for the font think it has a glyph for the euro char?

It should not assume this since I only had iso8859-1&adobe-symbol fonts in my
font path during the test.

Comment 41

[kill this account]

The whole encode scheme works on the assumption that the encoder knows what 
chars are in the font. So the question is: 

Does the encoder have the "correct" map for what is supposed to be in that 
font's registry-encoding (or familyName-registry-encoding for special fonts)?

Does the font support the chars that are implied by the font's registry-encoding 
(or familyName-registry-encoding for special fonts)?

Comment 42

[Roland Mainz]

I'll file a new bug for the issue described in comment #38 to move the
discussion&&investigation out of this one...

Comment 43

[Roland Mainz]

Requesting sr= ...

Comment 44

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 100734 [details] [diff] [review]
New patch for 2002-09-23-08-trunk

sr=roc+moz

Comment 45

[Simon Montagu :smontagu]

Fix checked in.

Comment 46

[Simon Montagu :smontagu]

... but backed out because the Mac tinderboxen went red and I couldn't find Roland.

Comment 47

[Zach Lipton [:zach]]

Attachment: Fix to add to the mac project files. Untested, but the possibility of bustage is better than known bustage ;)

Comment 48

[Roland Mainz]

Simon Montagu wrote:
> ... but backed out because the Mac tinderboxen went red and I couldn't find 
> Roland.

Sorry, I was side-tracked for a few mins...

... you said I have to write 1000 times "I have to change the Mac build files
when I add new files" ... ;-(
Do you want that as FAX or is an Email sufficient ? :)

Comment 49

[Jonathan]

Is this still an issue?

Comment 50

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:enndeakin, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 51

[Jonathan Kew [:jfkthame]]

At this point, I don't think this is relevant any longer. There are plenty of standard fonts with support for the Euro sign on all platforms.