while testing an EPS with uappend path definition, the path is not computed correctly, seems to be a path drop out resulting in a filled triangle instead of a thick line. Adobes products do the same correct.
Created attachment 5168 [details] tested eps This is the example eps: GhostScript produces a wrong computed userpath, adobes products samples correct.
Created attachment 8809 [details] Problem demo The problem is caused by strange handling of upath by Adobe interpreters and a deliberate use of this bug by the sample file. An user patch is supposed to be a self-contained path description. PLRM says on p.199 that the path is assumed to be empty initially, so the first operator after setbbox must be an absolute positioning operator (moveto, arc, or arcn). It's clear that the first arc operator cannot have an initial line segment. Adobe interpreters behave differently and create the line segment when the user path is concatenated with the current path. The sample program depends on this bug to split a long continuous user path into two. The arc operator used draws a zero-radius arc that doesn't have other purpose than exploiting the bug. The demo file has all the data extracted from the original file. The file looks similar to the adobe sample. If arc is replaced with moveto, the file looks like Ghostscript rendering the original sample.
Ghostscript follows the PLRM -- not some strange Adobe behavior (note that Distiller and other PS implementations may ALL be different). Since this is not a valid PS example, closing as INVALID since this appears to be a deliberate invocation of the condition. We have better things to do than investigate all of the marginally documented or minor things where we differ from Adobe PS (unless a "real world" driver uses/ needs the functionality). BTW, I encourage Alex to be more assertive in closing this kind of bug report.