Issue 18607 - linetype other then continous get EPS exported without width
Summary: linetype other then continous get EPS exported without width
Status: ACCEPTED
Alias: None
Product: Draw
Classification: Application
Component: code (show other issues)
Version: OOo 1.1 Beta2
Hardware: PC Windows 98
: P3 Trivial with 4 votes (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 21590 44747 76721 80189 (view as issue list)
Depends on:
Blocks:
 
Reported: 2003-08-25 07:57 UTC by cvogelbusch
Modified: 2013-02-07 22:15 UTC (History)
3 users (show)

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

Attachments
The reproduction did not work as I expected, so here is the example that has problems getting exported. (it contains german letters) (6.16 KB, application/octet-stream)
2003-08-25 08:12 UTC, cvogelbusch 		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 cvogelbusch 2003-08-25 07:57:04 UTC 
Hi,

this issue was found using StarOffice 6.1 Beta2 for Windows.

Reproduction:
Create any line, make it ultra fine dashed and give it a width, e.g. 0,02 Then
export it as EPS. (May be make one contiousline with width 0,02)
Result:
This ultra fine dashed line has a fixed width of one pixel. That means when I
zoom in it does not change it visible width. The contiousline however is
displayed corectly.

(Verified with Adobe Illustrator and Ghostscript (via DVI View)).
Comment 1 wolframgarten 2003-08-25 08:10:22 UTC 
Set to new.
Comment 2 wolframgarten 2003-08-25 08:11:27 UTC 
This is reproducible in a current internal version, too. Reassigned to
Sven. Please have a look.
Comment 3 cvogelbusch 2003-08-25 08:12:53 UTC 
Created attachment 8714 [details]
The reproduction did not work as I expected, so here is the example that has problems getting exported. (it contains german letters)
Comment 4 sven.jacobi 2003-09-08 11:57:42 UTC 
changed owner, set target to OOo 2.0
Comment 5 sven.jacobi 2003-09-12 14:45:27 UTC 
again assigning the owner.
Comment 6 thb 2003-09-12 19:14:39 UTC 
Cannot currently reproduce. Will check back with Wolfram.
Comment 7 thb 2003-09-15 11:25:28 UTC 
Ah, got it now. Well, the problem is that our EPS export tries to use
native PostScript primitives whereever possible. Thus, in the case of
hairlines, and for solid lines of any thickness, we simply use
PostScript strokes. Unfortunately, for dashed lines, this can lead to
flawed output for thick lines. Therefore, we generate polygonal output
in these cases, but since our polygons are integer-based internally,
the line thickness is rounded to the next integer (which, in this
case, was obviously zero).

I could evaluate whether it's possible to clamp the stroke width for
native PostScript strokes to those integer values, too.
Comment 8 thb 2003-09-15 12:35:58 UTC 
Okay, will see what's possible for OOo2.0 here. In principle, some
processing steps for thick line generation are already floating point,
should be possible to somehow get that data to the EPS exporter.
Comment 9 thb 2003-09-24 09:26:52 UTC 
-
Comment 10 marc.neumann 2003-10-16 08:49:44 UTC 
"According to the OpenOffice.org roadmap
(http://tools.openoffice.org/releases) this issue was retargeted to
OOo Later."
Comment 11 christian.guenther 2007-11-06 16:30:21 UTC 
*** Issue 21590 has been marked as a duplicate of this issue. ***
Comment 12 christian.guenther 2007-11-06 16:31:14 UTC 
*** Issue 44747 has been marked as a duplicate of this issue. ***
Comment 13 christian.guenther 2007-11-06 16:32:13 UTC 
*** Issue 76721 has been marked as a duplicate of this issue. ***
Comment 14 christian.guenther 2007-11-06 16:32:57 UTC 
*** Issue 80189 has been marked as a duplicate of this issue. ***
Comment 15 clement_r 2008-09-23 17:18:14 UTC 
Still there in 2.4.0
Comment 16 thb 2012-07-13 20:48:24 UTC 
Reset to default bug assignee.