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

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

Getting Rid Of PostScript

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

Contents

  Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-05 18:24 -0700
    Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-06 14:50 -0700
    Re: Getting Rid Of PostScript jdaw1 <jdawiseman@gmail.com> - 2016-10-06 15:45 -0700
      Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-06 17:44 -0700
      Re: Getting Rid Of PostScript Mark Carroll <mtbc@bcs.org> - 2016-10-07 08:47 +0100
        Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-07 15:08 -0700
          Re: Getting Rid Of PostScript luser droog <luser.droog@gmail.com> - 2016-10-07 18:47 -0700
          Re: Getting Rid Of PostScript Mark Carroll <mtbc@bcs.org> - 2016-10-08 12:34 +0100
    Re: Getting Rid Of PostScript luser droog <luser.droog@gmail.com> - 2016-10-07 18:39 -0700
      Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-07 19:07 -0700
        Re: Getting Rid Of PostScript luser droog <luser.droog@gmail.com> - 2016-10-12 15:32 -0700
          Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-12 17:06 -0700
          Re: Getting Rid Of PostScript rodd@panix.com (Rod Dorman) - 2016-10-13 19:07 +0000
            Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-13 15:02 -0700
              Re: Getting Rid Of PostScript rodd@panix.com (Rod Dorman) - 2016-10-14 20:13 +0000
                Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-14 14:39 -0700
                Re: Getting Rid Of PostScript Martin Leese <please@see.Web.for.e-mail.INVALID> - 2016-10-16 10:40 -0600
                  Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-17 18:06 -0700
                    Re: Getting Rid Of PostScript Alan <alan.isaac@gmail.com> - 2016-10-17 18:44 -0700
                      Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-17 22:43 -0700
                        Re: Getting Rid Of PostScript Martin Leese <please@see.Web.for.e-mail.INVALID> - 2016-10-18 10:13 -0600
                          Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-18 15:28 -0700
                          Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-18 15:35 -0700
                            Re: Getting Rid Of PostScript Ross Presser <rpresser@gmail.com> - 2016-10-18 23:05 -0700
                              Re: Getting Rid Of PostScript Carlos <angus@quovadis.com.ar> - 2016-10-19 19:23 +0200
                                Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-19 17:17 -0700
                                  Re: Getting Rid Of PostScript Ross Presser <rpresser@gmail.com> - 2016-10-21 09:18 -0700
                                    Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-21 18:10 -0700
                                Re: Getting Rid Of PostScript Ross Presser <rpresser@gmail.com> - 2016-10-21 09:14 -0700
                            Re: Getting Rid Of PostScript Markus Triska <triska@metalevel.at> - 2016-10-19 20:55 +0200
                              Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-19 17:57 -0700
                                Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-24 16:54 -0700
                                  Re: Getting Rid Of PostScript Carlos <angus@quovadis.com.ar> - 2016-10-25 16:26 +0200
                                    Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-25 10:32 -0700
                                      Re: Getting Rid Of PostScript Carlos <angus@quovadis.com.ar> - 2016-10-25 21:06 +0200
                                        Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-11-14 15:15 -0800
                                          Re: Getting Rid Of PostScript Carlos <angus@quovadis.com.ar> - 2016-11-16 00:17 +0100
                                            Re: Getting Rid Of PostScript Carlos <angus@quovadis.com.ar> - 2016-11-21 18:37 +0100
                                              Re: Getting Rid Of PostScript Carlos <angus@quovadis.com.ar> - 2016-11-21 18:39 +0100
                                  Re: Getting Rid Of PostScript Markus Triska <triska@metalevel.at> - 2016-10-25 20:52 +0200
                        Re: Getting Rid Of PostScript Alan <alan.isaac@gmail.com> - 2016-10-19 16:41 -0700
                          Re: Getting Rid Of PostScript Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-10-19 17:15 -0700

Page 1 of 3  [1] 2 3  Next page →

#2861 — Getting Rid Of PostScript

I recently reworked a Python script I created many years ago to lay out and print labels for audio CDs. This involves some intricate formatting of Unicode-encoded text, with leader tabs, left- and right-aligned fields, and also making sure that long track titles fitted into a fixed-width area.

Originally the script generated PostScript, which I fed through Ghostscript to generate a PNG file for printing. I just reworked the script to make direct Cairo calls to generate exactly the same layout.

Result? The code shrank from 386 lines to just 239. The single biggest saving was in the handling of Unicode-encoded text. My original routines for rendering the text originally looked like this:

    gs.write \
      (
        # theory of operation: the Decoding resource named Unicode is a dictionary
        # mapping glyphnames to Unicode character codes. However, multiple glyph names
        # can map to the same character code. I construct the inverse of this mapping,
        # where each character code maps to a dictionary with all the corresponding
        # glyph names as keys (and dummy values). To render a Unicode character,
        # I try all the glyph names corresponding to that character code until I
        # find a match in the CharStrings dictionary of the currentfont.
        "/UnicodeEncode 256 dict def\n" # initial size doesn't matter
        "/DefineCode\n" # glyphname charcode DefineCode -
          # inserts a correspondence between the specified glyph name and character
          # code into UnicodeEncode.
        "  {\n"
        "    UnicodeEncode 1 index known not\n"
        "       { % if\n"
        "        UnicodeEncode 1 index 1 dict put\n" # first glyph name for this character code
        "      }\n"
        "    if\n"
        "    UnicodeEncode exch get exch true put\n"
                # add another glyph name to dict for that character code
                # glyph name is key, value is unimportant
        "  }\n"
        "def\n"
        "/Unicode /Decoding findresource {DefineCode} forall\n"
          # mapping from Unicode character code to possible PostScript glyph names
        "/minus 45 DefineCode\n" # needed for Palatino-Roman
        "\n"
        "/UniShow\n" # chararray UniShow --
          # given an array of Unicode character codes, does a show of the corresponding
          # glyphs in turn. Assumes it's a Type 1 font.
        "  {\n"
        "      {\n"
        "        dup UnicodeEncode exch known\n"
        "          {\n"
        "            UnicodeEncode exch get\n"
        "            /.notdef exch\n" # in case no glyph name found
        "              { % forall\n"
        "                pop\n" # get rid of dummy value
        "                currentfont /CharStrings get 1 index known\n"
        "                  {\n"
        "                    exch pop\n" # get rid of .notdef, leave found key
        "                    exit\n"
        "                  }\n"
        "                  {\n"
        "                    pop\n"
        "                  }\n"
        "                ifelse\n"
        "              }\n"
        "            forall\n"
        "          }\n"
        "          {\n"
        "            pop /.notdef\n"
        "          }\n"
        "        ifelse\n"
        "        glyphshow\n"
        "      }\n"
        "    forall\n"
        "  }\n"
        "def\n"
        "\n"
        "/UniWidth\n" # chararray UniWidth xdelta ydelta
          # given an array of Unicode character codes, returns the width
          # of the complete string.
        "  {\n"
        "   currentpoint 3 2 roll\n" # save currentpoint (assumes there is one!)
        "   clippath pathbbox 4 2 roll pop pop\n"
        "   exch 100 add exch moveto\n" # guaranteed to be outside current clip
        "   currentpoint 3 2 roll UniShow currentpoint\n"
        "   3 2 roll sub 3 1 roll exch sub exch\n"
        "   4 2 roll moveto\n" # restore currentpoint
        "  }\n"
        "def\n"
        "\n"
        "/UniShowMaxFit\n" # chararray maxwidth UniShowMaxFit --
          # given an array of Unicode character codes, does a show of the corresponding
          # glyphs in turn, ensuring that the width of the string does not exceed
          # maxwidth.
        "  {\n"
        "    currentfont 3 1 roll\n" # save current font
        "    1 index UniWidth pop dup 2 index gt\n"
        "      {\n"
        "        div currentfont exch 1 matrix scale makefont setfont\n"
        "      }\n"
        "      {\n"
        "        pop pop\n"
        "      }\n"
        "    ifelse\n"
        "    UniShow\n"
        "    setfont\n" # restore previous font
        "  }\n"
        "def\n"
      )

The replacement Python code looks like this:

    def show_max_fit(ctx, text, maxwidth) :
        "shows text at the current position in ctx, temporarily adjusting the" \
        " font matrix so its width does not exceed maxwidth."
        save_font_matrix = None # to begin with
        width = ctx.text_extents(text).advance.x
        if width > maxwidth :
            save_font_matrix = ctx.font_matrix
            ctx.font_matrix *= Matrix.scale((maxwidth / width, 1))
        #end if
        ctx.show_text(text)
        if save_font_matrix != None :
            ctx.font_matrix = save_font_matrix
        #end if
    #end show_max_fit

Ah, but what about the “UniShow” and “UniWidth” routines, you are probably wondering? They were replaced with direct one-line Cairo calls. You can see instances of both of them in the “show_max_fit” routine.

[toc] | [next] | [standalone]

#2864

On Thursday, October 6, 2016 at 2:24:22 PM UTC+13, I wrote:
>
> Originally the script generated PostScript, which I fed through Ghostscript
> to generate a PNG file for printing. I just reworked the script to make
> direct Cairo calls to generate exactly the same layout.

Here’s another code saving: the routine for outputting tab leader characters from the end of the current column to the beginning of the next one. PostScript version:

    gs.write \
      (
            "/TabTo\n" # xpos TabTo --
              # outputs sufficient tab_char characters to move horizontal position to xpos
            "  {\n"
            "    %(origin_x)d add\n" # adjust for offset of label area
            "    dup currentpoint pop sub\n" # distance to move
            "    %(tabchar)s stringwidth pop div truncate cvi\n" # how many tab chars
            "    dup 0 lt {pop 0} if\n"
            "    {%(tabchar)s show} repeat\n" # draw the tab chars
            "    currentpoint exch pop moveto\n" # leave position at that desired
            "  }\n"
            "def\n"
        %
            {
                "origin_x" : area_origin[0],
                "tabchar" : psstring(tab_char),
            }
      )

Doing it all in Python:

    def tab_to(ctx, tab_char, x_pos) :
        "outputs sufficient tab_char characters to move horizontal position to xpos."
        startpos = ctx.current_point
        delta = Vector(x_pos - startpos.x, 0)
        nr_tab_chars = math.floor(delta.x / ctx.text_extents(tab_char).advance.x)
        ctx.show_text(tab_char * nr_tab_chars)
        ctx.move_to(startpos + delta)
    #end tab_to

I think the Python version is easier to understand, too.

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

#2866

Thank you for posting your ‘I†PS’ comments in a separate thread. 

I can open a PostScript with no special software — even on a work machine on which I lack Admin powers. You might wish to comment on how well Cairo copes in that regard.

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

#2867

On Friday, October 7, 2016 at 11:45:14 AM UTC+13, jdaw1 wrote:
> I can open a PostScript with no special software ...

But how do you render it?

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

#2868

On 06 Oct 2016, jdaw1 wrote:

> I can open a PostScript with no special software — even on a work machine on
> which I lack Admin powers. You might wish to comment on how well Cairo copes
> in that regard.

In fairness, Cairo generates decent PDF; I guess you'd exchange that if
it's just about reading. There are times when I've generated diagrams,
etc. illustrating data structures from algorithms I was describing,
directly from the actual code that uses the algorithms, where I chose to
have it produce PostScript directly but Cairo would absolutely have been
a viable alternative in that kind of case.

-- Mark

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

#2869

On Friday, October 7, 2016 at 8:47:01 PM UTC+13, Mark Carroll wrote:
> There are times when I've generated diagrams,
> etc. illustrating data structures from algorithms I was describing,
> directly from the actual code that uses the algorithms, where I chose to
> have it produce PostScript directly ...

Have you ever needed to generate interactive diagrams?

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

#2871

On Friday, October 7, 2016 at 5:08:02 PM UTC-5, Lawrence D’Oliveiro wrote:
> On Friday, October 7, 2016 at 8:47:01 PM UTC+13, Mark Carroll wrote:
> > There are times when I've generated diagrams,
> > etc. illustrating data structures from algorithms I was describing,
> > directly from the actual code that uses the algorithms, where I chose to
> > have it produce PostScript directly ...
> 
> Have you ever needed to generate interactive diagrams?

That is a need that I have attempted to supply.
There have in the past been the efforts of NeWS and
DPS to employ postscript in an interactive setting.
According to the literature, this approaches the 
original functionality of the ancestor JaM language.

https://github.com/luser-dr00g/xpost/blob/wiki/WhatIsXpost.md

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

#2874

On 07 Oct 2016, Lawrence D’Oliveiro wrote:

> On Friday, October 7, 2016 at 8:47:01 PM UTC+13, Mark Carroll wrote:
>> There are times when I've generated diagrams,
>> etc. illustrating data structures from algorithms I was describing,
>> directly from the actual code that uses the algorithms, where I chose to
>> have it produce PostScript directly ...
>
> Have you ever needed to generate interactive diagrams?

No, static PDF has always been the destination medium for me for
anything requiring high-quality output: grant proposals, technical
reports, that kind of thing. I've had to do some web stuff but for that
I always use straight JavaScript: jqPlot, etc. Many years back I also
did some interactive diagrams in Java applets but those were easily
coded in straight Java.

-- Mark

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

#2870

On Wednesday, October 5, 2016 at 8:24:22 PM UTC-5, Lawrence D’Oliveiro wrote:
> I recently reworked a Python script I created many years ago to lay out and print labels for audio CDs. This involves some intricate formatting of Unicode-encoded text, with leader tabs, left- and right-aligned fields, and also making sure that long track titles fitted into a fixed-width area.
> 

What about when you need precise text placement with
the actual font metrics with justifying any kerning?

I have a favorite pet postscript program that I
believe is best (perhaps even only possible in ps:
http://codereview.stackexchange.com/questions/117320/document-formatting-markup-engine-in-postscript

Does python+cairo help with a formatting markup language?

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

#2872

On Saturday, October 8, 2016 at 2:39:36 PM UTC+13, luser droog wrote:
> What about when you need precise text placement with
> the actual font metrics with justifying any kerning?

All that and more, with HarfBuzz and the rest of the Linux typography stack <http://default-cube.deviantart.com/gallery/59919308/HarfPy-Examples>. Full access to OpenType font features. Just enable/disable the ones you want, and the layout engine does the rest.

> I have a favorite pet postscript program that I
> believe is best (perhaps even only possible in ps:
> http://codereview.stackexchange.com/questions/117320/document-formatting-markup-engine-in-postscript

I see it requires you to manually set up kerning pairs, rather than automatically getting them from the font.

Remember, the font designer knows better than you how it should look.

> Does python+cairo help with a formatting markup language?

It would greatly simplify your code above, and give you access to more capabilities.

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

#2879

On Friday, October 7, 2016 at 9:07:59 PM UTC-5, Lawrence D’Oliveiro wrote:
> On Saturday, October 8, 2016 at 2:39:36 PM UTC+13, luser droog wrote:

> > I have a favorite pet postscript program that I
> > believe is best (perhaps even only possible in ps:
> > http://codereview.stackexchange.com/questions/117320/document-formatting-markup-engine-in-postscript
> 
> I see it requires you to manually set up kerning pairs, rather than automatically getting them from the font.
> 

That is indeed a defect in PostScript that I must concede.
There does not appear to be a standard way to access the
font's kerning tables.

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

#2880

On Thursday, October 13, 2016 at 11:32:54 AM UTC+13, luser droog wrote:
> There does not appear to be a standard way to access the
> font's kerning tables.

If you care about high-quality text, the two major reasons not to use PostScript any more are Unicode and OpenType.

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

#2882

In article <76c2a057-6627-4de9-88fc-ca3e1c37c256@googlegroups.com>,
luser droog  <luser.droog@gmail.com> wrote:
>On Friday, October 7, 2016 at 9:07:59 PM UTC-5, Lawrence D’Oliveiro wrote:
>> On Saturday, October 8, 2016 at 2:39:36 PM UTC+13, luser droog wrote:
>>> I have a favorite pet postscript program that I
>>> believe is best (perhaps even only possible in ps:
>>>
>http://codereview.stackexchange.com/questions/117320/document-formatting-markup-engine-in-postscript
>> 
>> I see it requires you to manually set up kerning pairs, rather than
>automatically getting them from the font.
>> 
>
>That is indeed a defect in PostScript that I must concede.
>There does not appear to be a standard way to access the
>font's kerning tables.

That's cause a PostScript font doesn't contain any kerning tables.

Kerning pairs are found in the fonts AFM file.

-- 
					-- Rod --
rodd(at)polylogics(dot)com

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

#2883

On Friday, October 14, 2016 at 8:07:52 AM UTC+13, Rod Dorman wrote:
> Kerning pairs are found in the fonts AFM file.

OpenType puts them in the font.

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

#2884

In article <1a6d41b2-6c18-4458-a18d-becdc92715a8@googlegroups.com>,
Lawrence Dā  Oliveiro  <lawrencedo99@gmail.com> wrote:
>On Friday, October 14, 2016 at 8:07:52 AM UTC+13, Rod Dorman wrote:
>> Kerning pairs are found in the fonts AFM file.
>
>OpenType puts them in the font.

Yes I'm aware of than but its irrelevant since there's no standard
PostScript font type that contains kerning pairs and if the font
doesn't contain them its kinda hard for a PostScript program to find
and read it.

-- 
					-- Rod --
rodd(at)polylogics(dot)com

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

#2885

On Saturday, October 15, 2016 at 9:13:56 AM UTC+13, Rod Dorman wrote:
>
> In article <1a6d41b2-6c18-4458-a18d-becdc92715a8@googlegroups.com>,
> Lawrence D’Oliveiro wrote:
>>
>> On Friday, October 14, 2016 at 8:07:52 AM UTC+13, Rod Dorman wrote:
>>
>>> Kerning pairs are found in the fonts AFM file.
>>
>> OpenType puts them in the font.
> 
> Yes I'm aware of than but its irrelevant since there's no standard
> PostScript font type that contains kerning pairs and if the font
> doesn't contain them its kinda hard for a PostScript program to find
> and read it.

Precisely why you should stop doing things in PostScript--see title.

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

#2888

Rod Dorman wrote:

> Yes I'm aware of than but its irrelevant since there's no standard
> PostScript font type that contains kerning pairs and if the font
> doesn't contain them its kinda hard for a PostScript program to find
> and read it.

Is it worth adding to the thread:
     Re: PostScript 4: Desiderata

a standard PostScript font type that contains
kerning pairs?

Note that jdaw1 has already requested:
    "A means to access kerning tables present
     in the font!  Ideally, convenient to
     use with `kshow`."

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

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

#2900

On Monday, October 17, 2016 at 5:40:54 AM UTC+13, Martin Leese wrote:
>
> Is it worth adding to the thread:
>      Re: PostScript 4: Desiderata
> 
> a standard PostScript font type that contains
> kerning pairs?

Even if you did, PostScript still wouldn’t be as good a graphics language as Python.

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

#2901

On Monday, October 17, 2016 at 9:07:05 PM UTC-4, Lawrence D’Oliveiro wrote:
> PostScript still wouldn’t be as good a graphics language as Python.

I don't even know what this claim means.  Python is not a graphics language.  It is possible to produce graphics using Python and certain libraries, which are often not written in Python.  For example, one can use Pycairo to get bindings to Cairo, which is a metalanguage written in C.  Using this metalanguage, once can output to a variety of formats, including PostScript or PDF.  The virtues of various metalanguages can be debated endlessly.  Certainly, for some goals it is preferable to use a metalanguage.  A great feature is when a metalanguage supports direct translation of PostScript, SVG, or possibly PDF.  (E.g., Mathematica provides some support for this.)  That way, one can get the best of both worlds.

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

#2903

On Tuesday, October 18, 2016 at 2:44:24 PM UTC+13, Alan wrote:
> On Monday, October 17, 2016 at 9:07:05 PM UTC-4, Lawrence D’Oliveiro wrote:
>
>> PostScript still wouldn’t be as good a graphics language as Python.
> 
> I don't even know what this claim means.

It means what it says.

> Python is not a graphics language.

Precisely the point. Yet it is a better one than PostScript.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web