Issue 10218 - PDF Export does not use Type 1 Fonts
Summary: PDF Export does not use Type 1 Fonts
Status: CLOSED IRREPRODUCIBLE
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: 643C
Hardware: PC Windows 2000
: P3 Trivial with 7 votes (vote)
Target Milestone: ---
Assignee: hdu@apache.org
QA Contact: issues@sw
URL:
Keywords:
: 17342 18399 19878 24868 40065 59106 (view as issue list)
Depends on:
Blocks:
 
Reported: 2002-12-19 16:41 UTC by Peter
Modified: 2013-08-07 14:38 UTC (History)
6 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
example of missing type 1 fonts (37.09 KB, application/pdf)
2002-12-19 16:43 UTC, Peter 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Peter 2002-12-19 16:41:42 UTC 
Type 1 Fonts are substituted with an improper true type font.
Comment 1 Peter 2002-12-19 16:43:29 UTC 
Created attachment 4106 [details]
example of missing type 1 fonts
Comment 2 h.ilter 2003-01-13 14:28:22 UTC 
In cause of that I haven't got the fonts in the attached file, could
you check this please.
Comment 3 philipp.lohmann 2003-01-13 15:05:34 UTC 
pl->hdu: you don't set the Embeddable flag in the ImplFontData then.
Comment 4 hdu@apache.org 2003-01-13 15:48:58 UTC 
 Unfortunately there is no W32 API to get the font file for a    
postscript font, so it cannot be embedded by apps without using  
dirty tricks. The GetFontData API would be perfect if it only worked  
for something other than TT fonts.   
   
Ideas how to get the file path of the currently selected font for PS    
fonts are welcome. Maybe there is a way to talk to the ATM? Need to   
investigate further...
Comment 5 h.ilter 2003-08-28 10:54:30 UTC 
*** Issue 18399 has been marked as a duplicate of this issue. ***
Comment 6 lohmaier 2003-09-26 18:59:29 UTC 
*** Issue 19878 has been marked as a duplicate of this issue. ***
Comment 7 hdu@apache.org 2003-10-10 09:29:00 UTC 
*** Issue 17342 has been marked as a duplicate of this issue. ***
Comment 8 hdu@apache.org 2003-10-15 13:34:29 UTC 
I will use the ATM API for this if ATM is available on the system.
Comment 9 hdu@apache.org 2003-10-15 14:08:08 UTC 
.
Comment 10 hdu@apache.org 2005-01-10 10:44:55 UTC 
*** Issue 40065 has been marked as a duplicate of this issue. ***
Comment 11 aziem 2005-12-09 14:05:40 UTC 
*** Issue 59106 has been marked as a duplicate of this issue. ***
Comment 12 mhp_nc 2005-12-09 16:14:16 UTC 
It is unfortunate to read that MS does not provide an API for this. I suppose it
is expected that they favor TrueType, rather than something invented by Adobe.

Probably OOo developers already are aware that (at least for Windows XP), the
font locations are stored in the Registry in the key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts

Not being a system programmer, I cannot say if that is easy or difficult to
access, now whether it works across windows versions.

If the problem can't be solved, a warning dialog would at least spare users
getting unexpected results that they need to troubleshoot.
Comment 13 hdu@apache.org 2006-01-02 15:12:14 UTC 
*** Issue 24868 has been marked as a duplicate of this issue. ***
Comment 14 vandan 2006-05-22 00:54:58 UTC 
Submitted in 2002? Hmmmmm.

Fine then. I'll resist the strong temptation to submit a duplicate in the hope
that it will get some attention ... I'll even vote for this bug ( which means
pulling votes from other bugs ) ... but how about a status update, please? As
far as I can tell, PDF export is completely useless in it's current state.
Comment 15 hdu@apache.org 2006-05-22 08:39:45 UTC 
Oops, the issue status needs to be updated.

Type1 fonts worked for quite some time on windows now. See issue 63015 for
remaining problems.
Comment 16 hdu@apache.org 2006-10-09 15:42:01 UTC 
Reopening for adjusting status.
Comment 17 hdu@apache.org 2006-10-09 15:45:45 UTC 
The issue has been resolved by other bugfixes. Should investigate which exact
fixes were responsible for the fix, but the time needed for bisecting and
analyzing all relevant changes is better spent somewhere else => changing status
to WORKSFORME
Comment 18 hdu@apache.org 2006-10-09 15:46:05 UTC 
.