Issue 10073

Created attachment 4032 [details]
As above.

Created attachment 4033 [details]
As above

Created attachment 4034 [details]
As above

Created attachment 4035 [details]
As above

reassigned to thb@openoffice.org
set Target to OO2.0

Hi James,

unfortunately your testfile "graphics.sxw does not wor on my PC: I can
not see any graphics in my file, only links to images.

Also I do not understand clearly how I should reproduce your problem.

Does this problem still exist in OOo 1.1.0?

If it does, please attach some OOo-documents that reproduce this
problem  here in the issue:
- Text- Document
- EPS- image
- cleat and simple step by step instruction how to reproduce that 
   problem:
  1. open textfile
  2. Menu: Insert-Graphic-FromFile
  3. and so on
 10. expected: print shoud show ... (or something like that)
      actual result:

If I will not see any further action as votes, attachments or
confirmations in this issue, I will have to close this issue
2003-10-31 as WFM.

CU

Rainer

Hi reporter,

if you want to supply new files, pls. have a look on issue 12591

Rainer

> unfortunately your testfile "graphics.sxw does not wor on my
> PC: I can
> not see any graphics in my file, only links to images.

Ah, "stupid broken program" :-)

Although I have selected the relative URLs for both files and Internet
they are still saved as absolute. You will have to either replicate my
file structure, or easier, edit the OOo document with your paths. I
think thers is a bug here (a special kind of issue which is a defect).


> Also I do not understand clearly how I should reproduce your
> problem.

Please read my first report.


> Does this problem still exist in "OOo 1.1.0"?

Yes. (2nd Print output attached.)


> If it does, please attach some OOo-documents that reproduce this
> problem  here in the issue:

> - Text- Document

Already done, attachment #2 [details]

> - EPS- image

Already done, attachment #1 [details]



> If I will not see any further action as votes, attachments or
> confirmations in this issue, I will have to close this issue
> 2003-10-31 as WFM.

EH? You said you can't make this work, "does not wor" (sic). So how
can you possibly say it "works for me"?

You obviously think I'm some kind of liar so attached is a screen grab
with showing that the print output does not match the requests not
preview in OOo.

James.

Created attachment 10181 [details]
2nd print put, but this time from 00o-1.1

Created attachment 10182 [details]
Screen grab showing difference between OOo and print.

> ------- Additional Comments From RainerBielefeld@openoffice.org 
2003-10-09 22:35 PDT 
> if you want to supply new files, pls. have a look on issue 12591

12591 is unrelated to this issue.

I can _not_ confirm the bug with 1.1.0 German version WIN98SE
645m19(Build8693)  and Printer HP895Cxi

My steps to reproduce:

0. download "graphic.eps"
1. open new text file
2. Menu: insert - graphic - from file
3. select and insert "graphic.eps"
4. insert some linefeeds and do 2.-3. two times to get 2 more images 
   on the page
5. select second inserted image
6. rightclick, image, flip horizontal, <OK>
7. select third inserted image
6. rightclick, image, flip vertical, <OK>
8. Print (py printer: HP 895Cxi)
   expected: flip horizontal and vertical as visible in the document
   actual: as expected.

Now with the same writer document:
11. Print with "Adobe generic postscript printer" 
   expected: flip horizontal and vertical as visible in the document
   actual: as reported, horizontal _and_ vertical flip are ignored.

So: --> NEW

I think that is serious for SOLARIS, as far as I know printout will
always go via postscript.

I changed subject to make it more meaningful.

Component "gsl" seems to be a better choice.

Rainer

rainer forgot to reassign to owner of selected subcomponent...
raising Prio to 3 (may be lowered since you can flip the graphic
before inserting it) and setting target-milestone to not determined.
OS to all since the same on linux and the same on windows when PS is
generated

Maybe eps figures cannot be flipped because OOo doesn't have it's own
PS-interpreter.
If this is the case and this issue probably can't be resolved in near
future, there should be at least some kind of notification saying 
"This operation is not possible with EPS-Figures" and/or OOo should
refuse to flip the preview (if present)

Again steps to reproduce:
O) Open a new textdocument
1) Insert an eps-figure
2) Flip the figure horizontally/vertically (doesn't matter)
3) Print to postscript

-> eps is printed as if it were not flipped.

> ------- Additional Comments From cloph@openoffice.org  2003-10-13
08:11 PDT -------

> raising Prio to 3 (may be lowered since you can flip the graphic
> before inserting it)

Not if it's shared which is part of the reason for referencing it and
not including (as the initial report).

Yes, an EPS can be copied and the raw PostScript edited but do you
really expect you average user to know how to hack PostScript? (Even
if only a simple flip wrapper.)

However I agree it's not a very important problem. If there was no
flip option I would not worry but if you provide the option it should
work; a weak solution would be to remove the option, at least the
option wouldn't be misleading and broken.

> If this is the case and this issue probably can't be resolved in
near
> future, there should be at least some kind of notification saying
> "This operation is not possible with EPS-Figures"

Not true.
A flip can be combined with the encapsulating scaling transform, (and
note how very easy it is to fix the flip problem).

See also issue #10074.

cp->pl: do we have any stakes in rotating eps ? please dig that out

We'd need to change the OutputDevice::DrawEPS method to accept a full
matrix instead of (effectively) a Rectangle. Then the filter people
would have to use it accordingly. I'll accept that as a 2.0 task.

cp: retargeted to Office-Later due to limited ressources

adding aw to CC

AW: It would be interesting to check if Draw/Impress/Calc behave different here
to Writer since Writer uses it's own implementation of GraphicObjects. It should
not make a difference since the primitive-based painting of the DrawingLayer
GraphicObject also uses OutputDevice::DrawEPS AFAIK, but would be good to check.

Reset assignee on issues not touched by assignee in more than 2000 days.