Issue 14163

These are actually 3 separate issues:

- type1 not exported in PDF: this is a windows only problem; the
problem is that windows does not support access to the font file
(GetFontData does not work for type 1 fonts). There is currently no
workaround known.

- EPS figures not included: I'll forward this issue to sj who would
probably be responsible for that; but since you cannot simply download
PostScript into PDF i doubt there is a solution for this; without a
PostScript interpreter EPS graphics are just so much ascii junk.

- printing on Linux: well, "works for me". Please provide more details
 using a separate issue.

issue1: I agree this is a problem. Yet I have a strong impression that RagTime (v5) manages to obtain the font files (for printing) under Windows. Maybe it just guesses; the default location as proposed by ATM is c:\psfonts ... Alternatively, this could be configurable via some advanced option. Those who use Type1 fonts under Windows generally know they're way around :)

issue2: is there no way to interface to an installed ghostscript for this?

issue3: I'll see with 1.0.3.1 . With 1.0.1 and a recent SO6 eval version, one problem I had was that a Palatino ttf font was picked that was not even in my X font path, instead of the Type1 version also present.

Concerning issue3: the issue is how to control which font is taken for printing; does this depend on the X font path order, or??

Regarding issue 3: The fonts are indeed taken from your X font path
plus  some directories (e.g. of an installed java) and whatever comes
out of /usr/sbin/chkfontpath (which on some distributions lists the
directories of a fontserver). Generally TrueType fonts are preferred
to Type1 because:
- we can subset them (that is only the needed glyphs are downloaded,
not the whole font).
- they have better hinting as well as embedded bitmaps for display
purposes whereas the difference on the printer is marginal.

You are right, there is currently not much control what font is used
for printing if there are multiple fonts with the same family name. As
a workaround you can give a font that is imported to OOo (with
spadmin) a different family name, but that is not a real solution.

Concerning issue3:
I agree that truetype fonts display better on screen, except in Acrobat (and indeed on printouts) where no difference is visible. But there can be metrics differences...
Concerning subsetting: ghostscript does, so it is possible...

I do have a suggestion for a workaround. You know that under Windows, one can configure whether or not to download fonts (T1 & ttf) to postscript printers. I don't, for my ghostscript distiller, and let ghostscript finds its own fonts. Why not provide a similar option for PDF distiller printers?

That is not done easily in PDF; to select a font you have to use a
font descriptor which is either TrueType or Type1; there is no way to
simply say "use Arial". While it is possible to omit the actual font
file (which is by the way the thing Adobe recommends NOT to do) it is
quite undetermined what the reader application will make out of it;
probably it would take the font according to what was given in the
font descriptor. You'd lose the ability to share the PDF as the font
will probably not be on any target system. Also the reader on another
computer may choose another font. Another problem is that this would
only work if you constrain yourself to ansi 1252 characters as you
cannot write Unicode to PDF but only single byte encodings which have
to be known at the time of PDF creation. So you need to know quite
specific details about the font and have to write them to the PDF
file; in these circumstances you don't want the reader to actually
select a different font file you don't know the properties of.

By the way PDF creation has nothing to do with a printer anymore; that
was the case in OOo 1.0.x on Unix systems, where you could create a
"printer" that was actually a ghosctscript filter.

Regarding subsetting of type1 fonts: this is certainly possible alas
currently we don't have code for it. It certainly would be a feature
worth using if we had as subsetting solves a lot of problems.

My suggestion about omitting fonts was (of course...) only for ghostscript/distiller based pdf generation :)
I haven't tried 1.1b under linux yet (no space): is there no support for ghostscript/distiller based pdf creation anymore? I'd hope there would be, as long as there are these issues with the native pdf creation...

Concerning the subsetting: how about libpdf? Or code from ghostscript? [both of which have undoubtedly been considered...]

About issue2 ([e]ps figures): can you include pdf figures (into documents and into the pdf stream)? A number of applications that usually create EPS can also generate pdf (Illustrator comes to mind), and otherwise ghostscript can...

Neither eps nor pdf can be embedded within a pdf document. A
possibility would be to render eps files via Ghostscript interface,
but the rendering output would be a bitmap graphic and all advantages
of vector graphics are lost. So I am not sure if this is a solution.

How then does pdflatex manage? I haven't used this myself, but a colleague asserts that with pdflatex, figures can (or have to) be in pdf format, and they appear as vector graphics in the resulting pdf.

Converting to bitmap would be acceptable as long as the resolution can be controlled -- e.g. to match the target printer. But in general it will increase the size...

I don't have enough time to support this bug, so this issue is
reassigned to THB, who perhaps has an idea.

As Philipp asked to have item 3 in a different issue, and implicitely rejected item1, I 
took over for item 2 and changed the title accordingly.

We're actually thinking 
for some time to include gs for proper EPS handling, including export to PDF and 
generation of previews if none is embedded. Although, to be honest, this issue has not 
exactly an urgent priority. So, let's see if we will make it for 2.0.

Regarding your question about inclusion of PDF embeds into exported PDF: yes, 
pdflatex does, so somehow, we should be able, too. I was already implicitely assuming 
this step when proposing linkage to gs for exporting EPS to PDF.

Added note to issue 15223 and issue 17632. They seem to be duplicates. 

Just a comment!

If you embed eps figures in your writer document and use the
"Adobe Acrobat Distiller" printer driver you get wonderfull
looking figures in your pdf and not only the eps preview (if it
is available).

It would be valuable to have this fixed or a warning during the pdf
export of OOo that the generated PDF files are unusable if they
contain eps figures.

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

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

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

-

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

PDF export in 1.1 is unusable to me without EPS export. So I will
continue to use ps2pdf. Preview of EPS is also important - best would
be to use gs. In addition ps2pdf could be called from OpenOffice as
well, and resulting PDF embedded, which is possible (see PDFLaTeX).

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

I just would like to emphasize that EPS support in PDF export is really
important for me, since vector graphics are unbeatable for printing.
Support for EPS graphics in OOo is already a good thing, but direct
export in PDF would be even better.

Since OOo 1.0, I print to postscript and use Acrobat Distiller to
convert to PDF, with a nearly perfect and compact result
(obviously, there is no vector to bitmap conversion in any of the two
translations).

Since a workaround exists, there is no emergency for me, but adding
this in release 2.0 would be fair!

I think there is one more in this context: colored EPS is exported
only black/white. Using KPrinter gives proper result.
More, I would like to emphasize Tomasz point about 'preview EPS',
which was already discussed in issue 12059. I would appreciate a
solution in this too.

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

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

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

set to OOo Later as agreed with MMP and THB

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

May I second what heracles said? Note: he works on Windows, and has a 
work-around through the Acrobat Distiller. The Linux work-around, which
involves printing to a PS file, and then using ps2pdf is *not* elegant. On
the other hand, it seems like it shouldn't be too hard to include.

I want to be clear just how important this issue is for academic users. For
submission to peer-reviewed journals, we need to submit pdf files on a 
regular basis. The figures we include are frequently best represented
as vector grahpics (in science, you can change 'frequently' to 'almost
always'). Embedded EPS files are usually the best option for this, although
I hear that the SVG format is starting to get popular.

I have to say I was *shocked* to find that OOo's writer puts the bitmap
preview in the pdf file, rather than the vector graphic. I consider this
a major bug, and I'm sad to see that MSC, MMP, and THB do not consider 
it an urgent fix. I respect your opinions, of course, but is there any 
way I could convince you to reconsider?

For example, I frequently give presentations to my co-workers about how
to optimize their graphics, choose optimal resolution, et. al. I would
*love* to be able to demonstrate OOo's ability to handle EPS graphics in
a pdf export. This would be huge!

Pretty please?
Thanks for considering it,

-bobsmith
(sorry if I'm just repeating motyl)

> The Linux work-around, which involves printing to a PS file, and then using 
> ps2pdf is *not* elegant

Run spadmin and create a PDF-converter, than you have your "Distiller", e.g. you
don't have to print to a file and run ps2pdf manually, the PDF-converter runs
the command for you (or better ps2pdf is nothing more than a script that passes
some options to gs, OOo can do that by itself and has predefined commandlines so
you don't have to find them out. You even have the choice whether you want to
use pipes or a temporary file)

> [...] is there any way I could convince you to reconsider?

Provide a patch? Find someone who can provide a patch? Pay developers to write a
patch,.. Fix all other issues so more ressources are left to work on this one?

Don't get this wrong, but ressources are limited and thus some issues have to be
retargeted. I myself would like to see this implemented earlier and voted for
this issue...

If you are running KDE, it is even more convenient to redirect the printer
output to kprinter. Is allows you not only to print to PDF, but also to send to
fax, mail, etc.
I'd love to have EPS (rendering) included in OO, as this would allow
presentations using EPS graphics and being presented online....

FWIW, the OOo PDF exporter seems to usually produce better PDF output than gs
(any version), especially when CJK fonts are involved---except that it cannot
handle EPS, which defeats that very advantage.

One thing I can't follow in the discussion is *why* rendering the Postscript
must result in a bitmap. From what I've read about the PDF format, if the input
really is EPS, the allowed Postscript operators can all be (rather trivially,
iirc) transformed into corresponding PDF operators. The real problem, it seems
to me, is not that we must render the Postscript and produce the bitmap, but
rather how to "render" the Postscript but in the process get back the raw stream
of operators. I can see this is not as straightforward as it theoretically
should be  though.

thb->acli: Nope, it's not that easy. For this to work, you need a PostScript interpreter like gs. Please be 
aware that PS is a programming language, whereas PDF is a mere render output (oversimplified, I 
know. But true in the context relevant here).

Yes, I *am* aware that PS is a programming language (and can program in PS level
;). I'm not saying that it is very straightforward, but at least theoretically,
it is not true that rendering PS *must* produce a bitmap.

The previous comment refers to using gs to render that bitmap; I have nothing
against the idea of using gs to somehow "render" the EPS into a stream of
Postscript operators. I know rendering PS is difficult; that's why I say I know
it's not as straightforward as it should be.

I haven't been following this issue for a while. I was under the impression that 
the bitmap used in the pdf export was the preview bitmap present in the eps 
file. Is it in fact created by gs on the fly, or is that being proposed?
Would it not be possible, in that case, to have gs generate pdf, and incorporate 
that? This is exactly what pdflatex does (meaning it is feasible.)

Actually, the ability to handle pdf figures would be great to have (pdf versions 
are often *much* smaller than their eps/ai originals)! But that would be another 
issue ;^)

Yes, I also think OOo embeds the preview bitmap of the EPS. I was referring to
comment #10 (if I counted correctly), which says that even if we render the EPS,
the rendering would result in a bitmap; I was trying to point out that this is
not  necessarily the case (and certainly well substantiated by the existence of
pstoedit).

So I guess you can call it a proposal :-)

Thanks for the many responses to my post. :-) I'm learning a lot.

I'd had the naive idea that rendering EPS (instead of the preview) 
into the PDF document would involve a simple ghostscript call, and 
would not be a big deal to implement. It looks like that's non-trivial.

The workarounds make this much less urgent than I thought; the 
only awkwardness is that the toolbar button (or the internal pdf 
exporter) should not be used when you have EPS graphics embedded. 
No big deal, as long as that's documented somewhere (I probably 
missed it).

Thanks for solving my immediate problem, anyway- it works fine
for me now. And keep up the good work. I didn't mean for my 
ignorance to distract attention away from more important issues.

The workarounds are anyway *only* for printing. It does not help when u want to
present directly from laptop using a beamer (and this is the way it mosly works
in business). Only chance is converting the images prior to embedding....

Present directly from within OO, or using Acrobat's slideshow/presentation 
feature? In the former case, EPS figures are just not appropriate. Even MS 
Powerpoint will show you the screen preview (if the EPS has one!), and not 
something else.

That said, this *is* one of the reasons why I personally only use Acrobat for my 
presentations.

Honestly, I'm not really interested whether ppt can do it or not - MS formats
dont care about any standards.
.
The point is that basically all unix output uses (e)ps format, so including
these images in a presentation is basically in its 'native' format. So there was
a big surprise that OO cant deal with this.
Anyway, will look at this Acrobat presentation feature.
Cheers

Well, as far as (business) presentations are concerned, ppt is a standard (not 
the format, the programme). It makes sense that a presentation system that 
basically uses your screen to present to does not support (e)ps, pdf or another 
vector-based format if the underlying graphics model doesn't. *Maybe* that 
you'll find this feature under Mac OS X (which is itself pdf based).
You might be able to display a nicely rendered version of an eps file if 
somebody implements a frontend to gs allowing it to be used as a 'plugin', just 
like you'd be able to show a .mov or .avi in your presentation. But I wouldn't 
count on much enthusiasm for such a suggestion as it is so easy to just make a 
bitmap version of the right size/resolution for this kind of purpose.

cmc->thb: I've attached a patch to issue 9290 which uses some external tools to
make a preview for eps if one doesn't exist (if the user has pstoedit installed
it looks very good indeed). Its assigned to bh, but perhaps you might be able to
consider it for inclusion as it gives a reasonable short-term solution to at
least the missing preview problem. 

I took a look at how pdflatex embeds pdfs in pdf, and it looks quite hard :-(

thb->cmc: well done, the patch looks promising. Will definitely consider taking
that for 2.0.  Regarding the discussion about how pdflatex and other tools
convert EPS to PDF: FWICT, it's basically the same thing pstoedit does, namely,
redefine all relevant PS output operators in a pre-included PS file, run both
through a postscript interpreter, and either generate custom output directly
from those overridden operators, or parse the interpreter output (that's what
pstoedit does).

oh sure, theres no mystery as to how pdflatex converts eps to pdf, the tricky
bit is how it inserts such a converted pdf into another pdf document :-).
pdflatex has a pdf importer which properly parses and reads the converted pdf
(that was originally eps) and adds it correctly to the pdf /Catalog of the
document that its inserting it into and adds the correct objects etc etc. So if
we wanted to convert the eps to pdf through some ghostscript pdf creating route
and then insert the result into a pdf its a good bit more difficult than it is
to insert an eps into a postscript file. Not impossible of course, but a fair
amount of work.

I see I'm not the only person who discovered this "issue" (=bug).
At the very least, there should be a big warning in the "Export to
PDF" dialog box that it doesn't handle EPS graphics properly, but
printing to distiller (or ghostscript) does. This would be a simple
"fix", and it would keep people like me off your back :-)

FWIW, a *lot* of applications hype their "save to PDF" or "Export
to PDF" features, and many of them turn out to have problems, so
you end up using distiller anyway. PDF is supposed to support
vector graphics, and it's a Big Deal if your implementation doesn't.

@cmc: I'm thoroughly underwater, and since you also have commit access: could
you handle this? After all, you've already provided the patch. Retargetting is
not a problem.

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

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

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

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

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

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

I would also like this feature very much. With all the nifty features the PDF
export has now (as of 2.0.4), using any of the workarounds is cetainly inferior
(maybe except for Adobe's Distiller). It is a shame that all these features are
wasted for people who require EPS to PDF export (forcing them to use one of the
workarounds).

So this should really be fixed :-)

Thanks in advance.

@sj: sorry, did not get the time to work on this. please take the issue back.

OpenOffice 3.0 is out. Issue stills open. When will be fixed? this is an
important issue to solve soon

I have been using either StarOffice or OpenOffice since the late 90's.  The main reason I began using 
this product was because of its ability to correctly print .eps files.  Earlier this year I was still using 
OpenOffice 1.0.3 (1.0.3) on Mac OX X 10.4.11 PPC G4.  I was able to insert an .eps file into either a text 
document or presentation or drawing, select File, Print, and Print to file using the Generic Printer driver, 
and end up with a .ps file that I could convert to .pdf using ps2pdf.  I now have a Mac OS X 10.5.5 Intel 
machine and have downloaded OpenOffice 3.0.0.  (1.0.3 runs but crashes often on my new Mac, else I 
would continue using 1.0.3.)  When I insert an .eps file now, the .ps and .pdf outputs are just a box 
with red text characters describing the file.  Why was OpenOffice 1.0.3 (and earlier versions) able to do 
this and not OpenOffice 3.0?  What is even more frustrating is that the new Mac version of PowerPoint IS 
able to correctly import, print, and even display on screen .eps files.  I may have to start using 
PowerPoint!  Please return this .eps functionality to OpenOffice.  Else I have one major reason to stop 
using it.  

brianhornbuckle: for printer and display see issue 93990 (which will be fixed in
3.0.1)

Please address this issue!  By "this issue" I mean properly printing eps files
from Windows.  It's not just exporting to pdf, but printing to postscript
printers too.  I've held off switching over to open office for several years
because of this issue.  I keep checking back, and all I see is "OOo Later" for a
target milestone.

I too would like GOOD support of a vector based file format which is compatible 
with most design programs out there.

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

I also want to argue that this is a Defect and not a mere "enhancement". 
I work in a large organisation of 180.000 employees, and all the predominant format for logos, special 
typography, and forms is either EPS or PDF. 

So my claim is that OpenOffice is not ready for prime time in the enterprise unless vector source 
information is also properly exported to PDF. 

Microsoft can do this. OpenOffice should also be up to the task. 

And albeit there are many comments that argue that EPS cannot simply be put into the PDF "stream", I 
wonder how complex the translation would be? PDF export from Microsoft or Adobe Products is rather 
quick, significantly quicker than any ghostscript rendering time, so either there is some patented, 
magic supersonic algorithms in those commercial products or there exists a smart way of transforming 
the EPS into the PDF stream without much re-rendering. 

How can I request promotion of this issue into a defect?

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

It has been pointed  out above that this is a major problem for users in the
business.  The only reason is not more so is that most day-to-day users don
attempt to produce reasonable quality documents.

But here is another reason to put this forward.  In the academic world most
graphics are also produced by eps or pdf.  That's day-to-day activity for any
one using LaTeX. At least for me, the missing feature is a deciding road block
against adopting OOO. 

This is a major issue for me, since most of my graphics files are vector graphics (the only way to have 
professional looking illustrations). This problem breaks my dream of replacing FrameMaker with 
OpenOffice - something that could otherwise have been done.

On the Mac, I found a partial workaround, that at least lets me print the illustratios to a PDF file. 
However, this solution doesn't seem to export PDF bookmarks as well, making the resulting PDF file 
unsuitable for any kind of reference materials.

Instead of exporting, I printed it to PDF using the PDF driver (I guess it is the Adobe PDF driver that 
comes standard with the Mac, but it could have been installed by the Creative Suite, I don't know for 
sure).

Paolo

> This is a major issue for me, since most of my graphics files are vector
> graphics (the only way to have 
> professional looking illustrations). This problem breaks my dream of
> replacing FrameMaker with OpenOffice - something that could otherwise
> have been done.

Yes, this is really a big limitation that no vector format is supported bug-free.

Use Inkscape and MS Word. PDF, EPS and other vector formats can be opened in
Inkscape and copy&pasted as "Enhanced metafile" into MS Word. This works fine!

(It does not works with OOo Writer properly since its "Enhanced metafile"
support is very buggy.)

Thanks, Norbert. My plan was to avoid depending on the big ones for my job, after the demise of 
FrameMaker for Mac, the under-development of the Windows version, and  Microsoft's choice of making a 
once professional word processor like Word a tool for writing office letters. Since this is not a forum, I 
would only like to underline the importance of some features to actually make Writer a replacement of 
FrameMaker and Word; support for vector graphics is an essential one.

Importing SVG seems to work these days (it's not perfect, but it's a base we can
start building on). Converting EPS to SVG should not be hard using external
software, and beats converting to WMF.

I'm surprised supporting EPS is so hard; it's supposed to be a subset of
PostScript so I don't think you can legally solve the Towers of Hanoi in EPS.
But then again, it's been a while since I last read any Postscript manual.

But lack of EPS still hurts me: I postprocess the OpenOffice generated PDF with
PDFTK to stick in my letterhead, which otherwise looks butt ugly when included
in EPSin EPS. Converting the letterhead to SVG that works with OOo is not a
trivial exercise either.

If SVG works out of the box for 95% of the stuff you can throw at it, I think an
acceptable way of dealing with EPS is requiring its conversion to SVG. But right
now, the SVG support isn't quite there.

fixing this issue would be an important step for OOo

I can not confirm that SVG works. I treid to use
http://upload.wikimedia.org/wikipedia/commons/0/09/49er_black.svg in a
presentation, only a black frame is printed!

This is a big issue for me as well, as almost all of my images are EPS format.  This bug has been around for over eight years now without resolution.  Is any progress being made on it?

I'd completely forgotten about this bug report...

Just as a thumbs-up:

- OOo 1.1.2 still works more or less on my MBP under 10.6, but only using Apple's X11 server, not the more actively updated XQuartz server

- LibreOffice seems to do *slightly* better than I understand OOo does nowadays. It can still not display, pdf-export or print Type1 fonts (it replaces my T1 Palatino font with a T1 (sic!) Times font). But when one prints to a PS printer, eps figures do get exported as such, and are thus converted properly into PDF by an Acrobat or Ghostscript distiller.

(In reply to comment #72)
 
> - LibreOffice seems to do *slightly* better than I understand OOo does
> nowadays. It can still not display, pdf-export or print Type1 fonts (it
> replaces my T1 Palatino font with a T1 (sic!) Times font). But when one prints
> to a PS printer, eps figures do get exported as such, and are thus converted
> properly into PDF by an Acrobat or Ghostscript distiller.

This has always been the case: Print to external PDF-printer works, internal PDF export or display does not handle EPS properly

So it did, apparently (as per my original report).

As for OOo 1.1.x - would it be possible to find a source tarball and build it under a current OS X release?