Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||EPS content is not exported to pdf properly|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||axel.braun, bas, caolanm, david.jurgens, diemer, irne.barnard, issues, jbf.faure, lohmaier, mfedyk, nicholas, norbert.notz, oo, openoffice.org, quetschke, t.bubeck|
|Target Milestone:||AOO PleaseHelp|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description rjvbertin 2003-05-06 16:12:13 UTC
PDF export: only truetype fonts are exported; Type1 (postscript) fonts are replaced by a truetype font. EPS figures are not included, their preview bitmaps are used instead. Printing: functions as expected under Windows. However, I never got the printing engine of OpenOffice 1.0x and StarOffice 6.0 under Linux to correctly print Type1 fonts in the text body. (Both actions seem quite slow in the 1.1beta)
Comment 1 philipp.lohmann 2003-05-06 16:59:49 UTC
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.
Comment 2 rjvbertin 2003-05-06 18:12:29 UTC
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 126.96.36.199 . 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.
Comment 3 rjvbertin 2003-05-06 19:50:13 UTC
Concerning issue3: the issue is how to control which font is taken for printing; does this depend on the X font path order, or??
Comment 4 philipp.lohmann 2003-05-07 10:05:36 UTC
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.
Comment 5 rjvbertin 2003-05-07 16:25:40 UTC
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?
Comment 6 philipp.lohmann 2003-05-08 10:00:51 UTC
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.
Comment 7 rjvbertin 2003-05-08 15:25:25 UTC
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...]
Comment 8 rjvbertin 2003-05-08 15:41:11 UTC
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...
Comment 9 sven.jacobi 2003-05-26 14:08:26 UTC
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.
Comment 10 rjvbertin 2003-05-29 15:39:17 UTC
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...
Comment 11 sven.jacobi 2003-06-26 11:54:04 UTC
I don't have enough time to support this bug, so this issue is reassigned to THB, who perhaps has an idea.
Comment 12 thb 2003-06-26 17:42:07 UTC
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.
Comment 13 thb 2003-06-26 17:49:55 UTC
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.
Comment 14 jensja 2003-07-30 18:54:03 UTC
Added note to issue 15223 and issue 17632. They seem to be duplicates.
Comment 15 quetschke 2003-08-29 18:24:57 UTC
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.
Comment 16 quetschke 2003-08-29 18:26:46 UTC
*** Issue 18456 has been marked as a duplicate of this issue. ***
Comment 17 lohmaier 2003-08-31 17:57:26 UTC
*** Issue 15223 has been marked as a duplicate of this issue. ***
Comment 18 lohmaier 2003-08-31 17:59:01 UTC
*** Issue 17632 has been marked as a duplicate of this issue. ***
Comment 19 thb 2003-09-12 18:48:23 UTC
Comment 20 christof.pintaske 2003-09-24 12:43:36 UTC
*** Issue 19947 has been marked as a duplicate of this issue. ***
Comment 21 motyl 2003-10-04 00:04:35 UTC
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).
Comment 22 lohmaier 2003-10-13 15:55:42 UTC
*** Issue 20990 has been marked as a duplicate of this issue. ***
Comment 23 Unknown 2003-10-30 10:00:25 UTC
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!
Comment 24 docb 2003-11-02 17:13:26 UTC
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.
Comment 25 philipp.lohmann 2003-11-04 17:48:32 UTC
*** Issue 21675 has been marked as a duplicate of this issue. ***
Comment 26 guido.pinkernell 2003-11-09 11:26:02 UTC
*** Issue 22250 has been marked as a duplicate of this issue. ***
Comment 27 lohmaier 2004-01-17 18:04:51 UTC
*** Issue 24453 has been marked as a duplicate of this issue. ***
Comment 28 marc.neumann 2004-02-02 08:35:10 UTC
set to OOo Later as agreed with MMP and THB
Comment 29 lohmaier 2004-02-25 20:30:40 UTC
*** Issue 20822 has been marked as a duplicate of this issue. ***
Comment 30 spudboy 2004-04-16 17:00:20 UTC
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)
Comment 31 lohmaier 2004-04-17 22:12:23 UTC
> 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...
Comment 32 docb 2004-04-19 06:29:15 UTC
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....
Comment 33 acli 2004-04-19 06:52:20 UTC
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.
Comment 34 thb 2004-04-19 10:17:18 UTC
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).
Comment 35 acli 2004-04-19 14:51:51 UTC
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.
Comment 36 rjvbertin 2004-04-19 15:11:16 UTC
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 ;^)
Comment 37 acli 2004-04-19 15:48:13 UTC
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 :-)
Comment 38 spudboy 2004-04-20 23:25:09 UTC
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.
Comment 39 docb 2004-04-21 09:43:19 UTC
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....
Comment 40 rjvbertin 2004-04-21 15:53:39 UTC
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.
Comment 41 docb 2004-04-21 17:24:58 UTC
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
Comment 42 rjvbertin 2004-04-21 17:49:36 UTC
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.
Comment 43 caolanm 2004-12-14 16:17:24 UTC
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 :-(
Comment 44 thb 2004-12-14 16:46:07 UTC
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).
Comment 45 caolanm 2004-12-15 08:08:16 UTC
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.
Comment 46 rbean 2005-01-15 04:32:44 UTC
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.
Comment 47 thb 2005-02-26 23:04:11 UTC
@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.
Comment 48 lohmaier 2005-05-26 22:17:47 UTC
*** Issue 49878 has been marked as a duplicate of this issue. ***
Comment 49 lohmaier 2005-08-25 20:11:22 UTC
*** Issue 53762 has been marked as a duplicate of this issue. ***
Comment 50 lohmaier 2005-10-30 16:37:40 UTC
*** Issue 56978 has been marked as a duplicate of this issue. ***
Comment 51 lohmaier 2006-01-27 14:09:22 UTC
*** Issue 61182 has been marked as a duplicate of this issue. ***
Comment 52 lohmaier 2006-02-25 15:25:33 UTC
*** Issue 62516 has been marked as a duplicate of this issue. ***
Comment 53 lohmaier 2006-07-31 21:16:31 UTC
*** Issue 67999 has been marked as a duplicate of this issue. ***
Comment 54 diemer 2006-10-16 16:16:28 UTC
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.
Comment 55 thb 2008-06-28 00:10:41 UTC
@sj: sorry, did not get the time to work on this. please take the issue back.
Comment 56 armandillo 2008-10-12 22:30:43 UTC
OpenOffice 3.0 is out. Issue stills open. When will be fixed? this is an important issue to solve soon
Comment 57 brianhornbuckle 2008-11-05 17:29:17 UTC
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.
Comment 58 philipp.lohmann 2008-11-05 17:36:56 UTC
brianhornbuckle: for printer and display see issue 93990 (which will be fixed in 3.0.1)
Comment 59 stderr42 2009-02-27 22:06:28 UTC
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.
Comment 60 qkrijger 2009-06-05 20:17:40 UTC
I too would like GOOD support of a vector based file format which is compatible with most design programs out there.
Comment 61 philipp.lohmann 2010-01-12 09:48:17 UTC
*** Issue 108218 has been marked as a duplicate of this issue. ***
Comment 62 thomas_ganter 2010-02-03 23:00:02 UTC
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?
Comment 63 h.ilter 2010-02-04 10:53:08 UTC
*** Issue 108906 has been marked as a duplicate of this issue. ***
Comment 64 edantes 2010-02-27 16:11:21 UTC
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.
Comment 65 ptram 2010-05-21 16:52:26 UTC
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
Comment 66 norbert2 2010-05-22 19:09:34 UTC
> 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.)
Comment 67 ptram 2010-05-24 09:35:36 UTC
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.
Comment 68 bertd 2010-06-24 01:52:17 UTC
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.
Comment 69 tommy27 2010-07-18 10:42:10 UTC
fixing this issue would be an important step for OOo
Comment 70 docb 2010-10-03 19:09:51 UTC
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!
Comment 71 david.jurgens 2011-07-19 20:48:34 UTC
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?
Comment 72 rjvbertin 2011-07-19 22:06:13 UTC
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.
Comment 73 docb 2011-07-20 05:58:47 UTC
(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
Comment 74 rjvbertin 2011-07-20 08:07:57 UTC
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?