'eofill'ing areas

[Michael Unger]

I want to create areas with transparent elements on a coloured
background. "eofill" is working exactly as expected within the
"35mmFilmFrame" procedure, but it isn't within the "Logo" procedure -- I
simply get coloured text on a transparent background instead of the
other way round.


---><8------><8------><8------><8------><8------><8------><8------><8---

%!PS-Adobe-3.0 EPSF-3.0
<< /PageSize [595.3 841.9]
>> setpagedevice
297.65 420.95 translate % center of page

/inch {72 mul} def

/35mmFilmFrame { % perforation vastly simplified
+0.7480 inch +0.7000 inch moveto
-0.7480 inch +0.7000 inch lineto
-0.7480 inch -0.7000 inch lineto
+0.7480 inch -0.7000 inch lineto
+0.7480 inch +0.7000 inch lineto
+0.7086 inch +0.4724 inch moveto
-0.7086 inch +0.4724 inch lineto
-0.7086 inch -0.4724 inch lineto
+0.7086 inch -0.4724 inch lineto
+0.7086 inch +0.4724 inch lineto
-0.6545 inch +0.5862 inch translate
+0.0190 inch +0.0550 inch moveto
-0.0390 inch +0.0550 inch -0.0390 inch +0.0350 inch 0.0200 inch arct
-0.0390 inch -0.0550 inch -0.0190 inch -0.0550 inch 0.0200 inch arct
+0.0390 inch -0.0550 inch +0.0390 inch -0.0350 inch 0.0200 inch arct
+0.0390 inch +0.0550 inch +0.0190 inch +0.0550 inch 0.0200 inch arct
eofill
} def

/Logo { % within the 24 mm x 36 mm film frame area
+0.7086 inch +0.4724 inch moveto
-0.7086 inch +0.4724 inch lineto
-0.7086 inch -0.4724 inch lineto
+0.7086 inch -0.4724 inch lineto
+0.7086 inch +0.4724 inch lineto
/Helvetica-Bold 36 selectfont
+0.0000 inch -0.0500 inch moveto
(test) stringwidth pop -0.5 mul 0 rmoveto
(test) true charpath
eofill
} def

0.0 0.0 0.8 0.0 setcmykcolor
Logo
0.1 0.0 0.0 0.9 setcmykcolor
35mmFilmFrame

---><8------><8------><8------><8------><8------><8------><8------><8---


There is _no_ difference whether "true" or "false" is used as the second
parameter for the "charpath" command. What am I doing wrong? (Adobe
Distiller from Acrobat 6.0 Standard, Windows; no more recent version
available)

Michael

--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.

[Helge Blischke]

No idea what is going wrong with Distiller. I fed the file through
Ghostscript (version 9.07) (only appended a showpage to the end), and the
result seems OK.
Perhaps the missing showpage is the culprit.

Helge

[luser- -droog]

On Sunday, March 10, 2013 12:46:27 PM UTC-5, Michael Unger wrote:
<snip>

> There is _no_ difference whether "true" or "false" is used as the second
>
> parameter for the "charpath" command. What am I doing wrong?

Nothing wrong here. The boolean argument to charpath only makes a difference with a "stroked" font, which nobody uses.

[Michael Unger]

On 2013-03-10 22:22, "Helge Blischke" wrote:

> No idea what is going wrong with Distiller. I fed the file through
> Ghostscript (version 9.07) (only appended a showpage to the end), and the
> result seems OK.
> Perhaps the missing showpage is the culprit.

No, it isn't; it doesn't make any difference at all whether there is a
"showpage" command in the PostScript code.

Another observation: It also doesn't make a difference if the font is
just referenced (as shown in the example) or embedded (as a PostScript
level 3 font dictionary).

Rather strange ...

[Helge Blischke]

Michael Unger wrote:

> On 2013-03-10 22:22, "Helge Blischke" wrote:
>
>> No idea what is going wrong with Distiller. I fed the file through
>> Ghostscript (version 9.07) (only appended a showpage to the end), and the
>> result seems OK.
>> Perhaps the missing showpage is the culprit.
>
> No, it isn't; it doesn't make any difference at all whether there is a
> "showpage" command in the PostScript code.
>
> Another observation: It also doesn't make a difference if the font is
> just referenced (as shown in the example) or embedded (as a PostScript
> level 3 font dictionary).
>
> Rather strange ...
>
> Michael
>

Dies the Acrobat 6 distiller emit any log messages?

Helge

[Michael Unger]

On 2013-03-11 18:02, "Helge Blischke" wrote:

> Dies the Acrobat 6 distiller emit any log messages?

There are log files created, but they are _very_ short (long line
wrapped for readability):

---><8------><8------><8------><8------><8------><8------><8------><8---

Processing prologue.ps...
Done processing prologue.ps.
Warning [DSC]:
PostScript code in the prolog should be in the procset resources
Processing epilogue.ps...
Done processing epilogue.ps.

---><8------><8------><8------><8------><8------><8------><8------><8---

Sometimes when external code snippets are invoked ("run") there are more
DSC warnings.

[Michael Unger]

On 2013-03-13 11:59, "Helge Blischke" wrote:

> Probably it is an distiller issiue with the charpath operator.

Apparently, yes, and a rather nasty bug.

> The path
> generated by charpath should be appended to the current path (according to
> the PLRM) but it seems the distiller's implementation clears the current
> path in advance.
> I tested this with Mac OS X pstopdf utility (which is used with the preview
> application as well).
>
> [...]

I tried another approach as well: using "eoclip" instead of "eofill" to
define just a clipping area, and then re-drawing the rectangle and
filling it, which didn't work either.

So I'll have to print white text onto a coloured background.

By the way: using the "charpath" operator with a simple "clip" to define
a clipping area _does_ work as expected. Therefore the bug may as well
be within Distiller's "even-odd" logic.

[Helge Blischke]

Michael Unger wrote:

> On 2013-03-13 11:59, "Helge Blischke" wrote:
>
>> Probably it is an distiller issiue with the charpath operator.
>
> Apparently, yes, and a rather nasty bug.
>
>> The path
>> generated by charpath should be appended to the current path (according
>> to the PLRM) but it seems the distiller's implementation clears the
>> current path in advance.
>> I tested this with Mac OS X pstopdf utility (which is used with the
>> preview application as well).
>>
>> [...]
>
> I tried another approach as well: using "eoclip" instead of "eofill" to
> define just a clipping area, and then re-drawing the rectangle and
> filling it, which didn't work either.
>
> So I'll have to print white text onto a coloured background.
>
> By the way: using the "charpath" operator with a simple "clip" to define
> a clipping area _does_ work as expected. Therefore the bug may as well
> be within Distiller's "even-odd" logic.

I don't think it is the even-odd logic.As you see from my attached example,
the rectangular path is present prior to the execution of chaqrpath but has
disappeared afterwards.

>
> Michael
>
Helge

[Olle]

This seems to be a pretty old thread already, but here goes:

I have Acrobat Pro X, and it seems to be font dependent for some reason. First of all it cannot use the font specified and uses a replacement (whatever that is) instead.

I used pathforall to find out if there was something funny in the path generated, but couldn't see any:

...
closepath
{exch == == (moveto) =}
{exch == == (lineto) =}
{6 2 roll 4 2 roll exch == == exch == == exch == == (curveto) =}
{(closepath) =}
pathforall
flush
eofill
...

But it works as expected with Courier... Hmm.

Thanks,

Olle

[Olle]

(For the pathforall test I replaced the test string with a hyphen to make it simple.)

Thanks,

Olle

[luser- -droog]

Which font fails? It might be that Acrobat can only do this with PS fonts, not TrueType.

[Michael Unger]

On 2013-03-20 21:28, "luser- -droog" wrote:

> Which font fails? It might be that Acrobat can only do this with PS fonts, not TrueType.

Just with respect to my experiments -- the original fonts are TrueType
fonts. I've created MS Word documents containing the relevant glyphs
A...Z, a...z, 0...9 (and a few others) and created a PDF document from
that using Acrobat 6 Standard (rather old admittedly). Finally I've used
Acrobat with "save as EPS" and "[x] convert TrueType fonts to PostScript
fonts" (or similar, I don't remember the exact phrasing) and extracted
the font information from that.

The result is then embedded as a PostScript level 3 font dictionary into
my programs, for example (showing just the "period" glyph):

| /ABCDEF+OptimaLT
| << /FontType 1
| /FontMatrix [0.001 0 0 0.001 0 0]
| /Encoding ISOLatin1Encoding
| /FontBBox [0 0 0 0]
| /PaintType 0
| /Private
| << /|- {def}
| /| {put}
| /BlueValues [0 0]
| /Password 5839
| /MinFeature {16 16}
| /Subrs
| [<1C60D8A8CC31FE2BF6E07AA3E541E2> <1C60D8A8C9C3D06D9E>
| <1C60D8A8C9C202D79A> <1C60D8A849>
| <1C60D8A8CC3674F41144B13B77>]
| /OtherSubrs
| [{} {} {} {systemdict /internaldict known not {pop 3}
| {1183615869 systemdict /internaldict get exec dup
| /startlock known {/startlock get exec} {dup
| /strtlck known {/strtlck get exec} {pop 3} ifelse} ifelse}
| ifelse} executeonly]
| >>
| /CharStrings
| << /.notdef
| <1C60D8A8C9B854D00D>
| /space
| <1C60D8A8C9B854D00D>
| /period
| <1C60D8A8C9B854D0ED1EFCAE87DC2FD148747CF8209152983DF13290A098
| 1A95FE8A38221E1CA30B7BCA347D12229301D0EAAEBE7CFF9A6A629E95F74
| 357C9866243F6F3C4>
| >>
| >> definefont

[Helge Blischke]

I don't think it is a font type issue:
I noted earlier that the Mac OS X Preview application exhibits the same
error, and I just repeated the test with a Type1 font included in the PS
file, and the issue result is as bogus as before.

Helge