Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #1298 > unrolled thread

'eofill'ing areas

Back to article view | Back to comp.lang.postscript

Contents

  'eofill'ing areas Michael Unger <spam.to.unger@spamgourmet.com> - 2013-03-10 18:46 +0100
    Re: 'eofill'ing areas Helge Blischke <h.blischke@acm.org> - 2013-03-10 22:22 +0100
      Re: 'eofill'ing areas Michael Unger <spam.to.unger@spamgourmet.com> - 2013-03-11 17:31 +0100
        Re: 'eofill'ing areas Helge Blischke <h.blischke@acm.org> - 2013-03-11 18:02 +0100
          Re: 'eofill'ing areas Michael Unger <spam.to.unger@spamgourmet.com> - 2013-03-12 18:45 +0100
            Re: 'eofill'ing areas Helge Blischke <h.blischke@acm.org> - 2013-03-13 11:59 +0100
              Re: 'eofill'ing areas Michael Unger <spam.to.unger@spamgourmet.com> - 2013-03-13 18:00 +0100
                Re: 'eofill'ing areas Helge Blischke <h.blischke@acm.org> - 2013-03-13 18:20 +0100
                  Re: 'eofill'ing areas Olle <olavi.sakari@gmail.com> - 2013-03-19 00:25 -0700
                    Re: 'eofill'ing areas Olle <olavi.sakari@gmail.com> - 2013-03-19 00:31 -0700
                    Re: 'eofill'ing areas luser- -droog <mijoryx@yahoo.com> - 2013-03-20 13:28 -0700
                      Re: 'eofill'ing areas Michael Unger <spam.to.unger@spamgourmet.com> - 2013-03-21 17:30 +0100
                        Re: 'eofill'ing areas Helge Blischke <h.blischke@acm.org> - 2013-03-21 17:52 +0100
    Re: 'eofill'ing areas luser- -droog <mijoryx@yahoo.com> - 2013-03-10 18:48 -0700

#1298 — 'eofill'ing areas

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.

[toc] | [next] | [standalone]

#1300

Michael Unger wrote:

> 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
> 

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

[toc] | [prev] | [next] | [standalone]

#1309

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

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

[toc] | [prev] | [next] | [standalone]

#1310

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

[toc] | [prev] | [next] | [standalone]

#1311

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

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

[toc] | [prev] | [next] | [standalone]

#1313

[Multipart message — attachments visible in raw view] — view raw

Michael Unger wrote:

> 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
> 

Probably it is an distiller issiue with the charpath operator. 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).

For demonstrating this bug, I slightly modified your PS job by 
- only rendering the logo
- replacing the eofill by stroking

You will see that only the "test" outline gets visible, but if you
uncomment the line
% gsave 0 setgray 0.5 setlinewidth stroke grestore % uncomment this line for 
you will see the enclosing rectangle as well, which in this case is only 
retained because the stroke is enclosed in gsave and grestore

Helge

[toc] | [prev] | [next] | [standalone]

#1314

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.

Michael

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

[toc] | [prev] | [next] | [standalone]

#1315

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

[toc] | [prev] | [next] | [standalone]

#1329

On Wednesday, March 13, 2013 7:20:49 PM UTC+2, Helge Blischke wrote:
> 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

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

[toc] | [prev] | [next] | [standalone]

#1330

On Tuesday, March 19, 2013 9:25:41 AM UTC+2, Olle wrote:
> On Wednesday, March 13, 2013 7:20:49 PM UTC+2, Helge Blischke wrote:
> 
> > 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
> 
> 
> 
> 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

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

Thanks,

Olle

[toc] | [prev] | [next] | [standalone]

#1331

On Tuesday, March 19, 2013 2:25:41 AM UTC-5, Olle wrote:
> On Wednesday, March 13, 2013 7:20:49 PM UTC+2, Helge Blischke wrote:
> 
> > 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
> 
> 
> 
> 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

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

[toc] | [prev] | [next] | [standalone]

#1332

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

Michael

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

[toc] | [prev] | [next] | [standalone]

#1333

Michael Unger wrote:

> 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
> 
> Michael
> 

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

[toc] | [prev] | [next] | [standalone]

#1301

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web