Apache OpenOffice (AOO) Bugzilla – Issue 68808
Embedded EPS suffers vertical offset after pre-processing
Last modified: 2006-08-22 08:40:15 UTC
OK, I know... this has been discussed before but it doesn't seem to go anywhere and I'd really like to do this... but classify me as 'not having much of a clue'. Anyway, maybe it's really a PATCH. I am trying to write some documentation where it would be useful to rip off sections of PDF files and embed them in the document. After a few tears I came back to this Open Office thing because I'd spotted the Insert Picture part that will grab an .eps file. I don't care that it just places a placeholder in the document. I don't care that it doesn't do the job via the internal PDF export. I do know that, using winsteng from adobe and a colour printer thing during the setup, I can print things from other things in .eps format. Then, using ghostscript I can convert them to .pdf and all is well. I can also use the same method on an Open Office document.... However, when I embed an .eps file in the document and then print the document to a .ps or .eps file and run it through ps2pdf it decides to dissapear off the top of the page. One thing I noticed is that before the .eps file gets imported into the document there is some pre-processing that goes on. There is some sort of call to... c:\windows\system32\convert.exe followed by C:\Program Files\gs\gs8.54\bin\gs32winc.exe Now, I'm assuming that because the original .eps file is the size it is (as printed) and the size on the document is going to be different, due to margins and position, it needs to get scaled and offset so that's why the calls are made. After the pre-processing it gets stuck on the document as an outline and the 'new' eps 'instructions' are saved in the file for later use(?) Unfortunately it looks like something goes wrong when the translation is made by the other two bits of software, either they get some wrong parameters passed to them or they are just.... whatever. I've looked at the eps file from an original print and then one after import and printing and the part that contains the 'picture' seems to be the same. However there are differences in the surrounding eps code that I couldn't begin to understand...... Anyway. Hope that makes sense to someone. Cheers Keith
convert or ghostscript are only used to create a preview image for OOo (since it cannot handle display eps files themselves. However, only one of the two should be used (so either your convert.exe is not ImageMagick or fails for another reason and it falls back to ghostscript) - and more important: It should not alter the way the eps is printed to postscript-capable printers. Ghostscript sometimes doesn't get the bounding-box right, but that should only affect the display in OOo, not in the generated postscript. Please attach the before and after documents to have a closer investigation. and please explain what you mean with "surrounding eps code"
please attach the offending document to this issue, so that we can reproduce and fix the problem here. You can also send the document directly (mru@openoffice.org) for the case it contains confidential data. Feel free to re-open the issue when you've done. Thanks for supporting us!
Unfortunately.... it looks like one of those things that decided to change its mind :-( Probably user error. I've been looking at it further and it seems there is some problem when printing from the software I'm using, a PCB design package, using the eps printer and requesting the output in landscape or rotated landscape. Portrait is OK. It looks like it is at that stage that the print gets incorrectly cropped. I can print portrait and guess at an amount to crop by in Open Office to make things right. I'll look harder but at the moment it seems the fault lies elsewhere. Sorry about that one. Cheers Keith
Closed.