set to "NEW"

MRU->US: please give your comment on this.

It's not that OOo doesn't like ITC but it tries to strip the XLFD font name so
that only the font family name gets displayed (the foundry field is as you
encountered also stripped). This has proven to work quite well now for a long time.
Unless you don't explicitly mention what "problems" this shall have on
"exchanging documents" I see no reason to change this. Thus the real issue seems
to be something else? Please describe.

The underlying intention is clear and honest.

Given, for example, font Garamond-Light, with name "ITC Garamond Light". On
Linux, the font name is stripped to "Garamond". When I save a document with that
font, the font name "Garamond" is saved with the document.

Exactly the same font (same .ttf) on Windows produces the font name "ITC
Garamond". When opening the (Linux) document on Windows, it cannot find the
correct font. Worse, it will try to use the font "Garamond" that happens to be
present on Windows, but with different typefaces and metrics.

IIRC, ITC added the prefix "ITC" to the font name to prevent it from being mixed
up with other Garamond fonts, just like many other foundries add pre- and postfixes.

Personally, I think stripping the ITC prefix is wrong. But the main problem is
the difference in treatment between platforms. If you insist on stripping the
prefix, then strip it on Windows as well.

Thanks for the update. So the problem is clear to me now.

On the other hand on Un*x you'll often find font aliases of the type
"Avantgarde" -> "ITC Avant Garde" (e.g. on Solaris 9). This example proves that
the current font name heuristic is  reasonable. Otherwise you'll get a long font
list with lots of dupes.

Regarding the mentioned different font naming on Windows compared to Un*x, I'll
guess this is due to different APIs. HDU, can you comment on this? 

Assuming the latter assumption is true, the only way out for OOo would be to
port the Un*x font name heuristic to Win32 to achieve consistency. Besides the
expenses of such a port (development, QA efford, bloating code) I bet that we'll
catch new issues, this time in the area of MS document import on Win32, choosing
wrong fonts :-(

seems to be a dupe of issue 3730 if so, please close one or the other...

In a way it is related to 3730, but I'd consider this a separate bug since it
only affects the ITC prefix, while 3730 addresses a much more general issue.

I think the problem is clear, and each alternative solution has its pros and
cons. So I'd suggest to add a user option in OpenOffice.org > Fonts. This way it
is up to the user to decide whether to go for legacy compatibility, or correctness.

I someone can hint me how to add user options, I may provide a proof-of-concept
implementation.

HDU->CP: please decide based on the pros and cons outlined above...

no additional UI changes for 2.0. I hope to address ease of use of fonts in the
next release after 2.0 

cp->hdu: please push on your pile

I can confirm this for 2.4 and 3.0beta. This bug is still present.

All Bitstream ITC fonts, are incorrectly displayed without the ITC prefix.

In one case, it even clashes with another fonts:

* Bitstream ITC Garamond incorrectly displayed as "Garamond" should be "ITC
Garamond"
* Monotype Garamond correcty displayed as "Garamond"

This is very bad behaviour! OpenOffice.org should not be "intelligent" about
font naming, unless stuff is missing. Fonts should be displayed exactly as they are.

Please fix it for 3.0 final.

I've reported this as well to Ubuntu's Launchpad:

https://bugs.launchpad.net/openoffice/+bug/118370

Well, the change from OOo2 to OOo3 is a chance to fix this => retargeting

I have no clue what the original idea behind that ITC-substring-stripping magic was, but the OOo2-
>OOo3 change is a chance to get rid of it... => done in CWS vcl89

verified

the change got into DEV300_m22 => closing

*** Issue 78497 has been marked as a duplicate of this issue. ***