groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] gropdf(1) Has Ugly Thick Lines by Default.


From: Ralph Corderoy
Subject: Re: [groff] gropdf(1) Has Ugly Thick Lines by Default.
Date: Mon, 30 Jul 2018 13:23:04 +0100

Hi Deri,

Thanks for the very prompt reply.  Sorry if I seemed grumpy; just time
pressure from deviating down another rabbit hole.  :-)

>     V2000
>     H72000
>     DFd
>     v2500
>     md
>     s10000
>     Dl 13330 0
>     n2000 0
>
> So it looks like the horizontal position of the start of the line is
> 72000 millipoints in and 4500 millipoints down from the top of the
> page and is 13330 millipoints long. This is what the postscript file
> contains:-
>
>     85.33 4.5 72 4.5 DL
>
> Which seems correct.

Agreed, 85.33 being 72+13.330.

> One difference between postscript and pdf is that ps has page origin
> at the top left whereas pdf uses the bottom left. Since the page is A4
> the top of the page is 842 points so gropdf using 837.5 is expected.

An aside, is it understood that A4 is precisely 842 points at 1/72th
inch in these file formats, that not being 297 mm?

    $ for p in {metric,printers,tex,computer,postscript}point; do
    >     units $p | sed "s/Definition/$p/"
    > done
            metricpoint: 3|8 mm = 0.000375 m
            printerspoint: oldpoint = 1|72.27 inch = 0.0003514598 m
            texpoint: oldpoint = 1|72.27 inch = 0.0003514598 m
            computerpoint: 1|72 inch = 0.00035277778 m
            postscriptpoint: computerpoint = 1|72 inch = 0.00035277778 m
    $
    $ dc -e '10k 297 25.4/ 72* p'
    841.8897637776

> >     720.25 8374.25 m      % Move.
> >     853.25 8374.25 l      % Line.
>
> It appears that the difference in coordinates is being introduced by
> conversion from postscript to pdf!

Yes.  This is all groff 1.22.3-7, and ghostscript 9.23-1, I forgot to
say.

I did wonder if it was from the PDF to QDF by qpdf(1) so I slimmed down
the table and used both `qpdf -qdf' and `mutool clean -d' to check,
producing filenames that show the path taken.

    .TS
    l.
    _
    \(en
    .TE
    E

    grops by groff -dpaper=a4 -Tps
        line-grops.ps                               77 4.5 72 4.5 DL
        line-grops-ps2pdf-pdf2ps.ps                 720.25 8374.25 m 770.25 
8374.25 l
        line-grops-ps2pdf-qpdf.qdf                  720.25 8374.25 m 770.25 
8374.25 l
        line-grops-ps2pdf-mutool.pdf                720.25 8374.25 m 770.25 
8374.25 l
        line-grops-ps2pdf-pdf2ps-ps2pdf-mutool.pdf  720.25 8374.25 m 770.25 
8374.25 l

    gropdf by groff -dpaper=a4 -Tpdf -P-d
        line-gropdf.pdf         72 837.5 m 77 837.5 l
        line-gropdf-pdf2ps.ps   720 8375 m 770 8375 l
        line-gropdf-qpdf.qdf    72 837.5 m 77 837.5 l
        line-gropdf-mutool.pdf  72 837.5 m 77 837.5 l

842 - 4.5 = 837.5 so both grops and gropdf get that right, but ps2pdf
shifts it.  Note the last grops item shows two ps2pdf steps, returning
back to PostScript inbetween, and doesn't double-shift the line.

And with a bit of guesswork, I get the same directly from the PDF from
ps2pdf.

    $ LC_ALL=C egrep -boam2 '^stream|endstream' line-grops-ps2pdf.pdf
    61:stream
    185:endstream
    $
    $ python -c '
    > import zlib
    > f=open("line-grops-ps2pdf.pdf", "rb")
    > f.seek(61 + 6)
    > s=f.read(186 - (61 + 6))
    > print(zlib.decompress(s[3:], -15))
    > '
    ...
    720.25 8374.25 m\n
    770.25 8374.25 l\n
    ...
    '
    $

> It does not seem to be associated with the linecaps, nor the length of
> the line, since using a very wide (10pt) linewidth and longer line
> does not alter the amount it is shifted.

I think both grops and gropdf are consistent with their `1 setlinecap',
round caps, and `1 setlinejoin', round corners.

I altered the PostScript from grops to

    .4 LW
    77 4.5 72 4.5 DL
    /F0 10/address@hidden SF<20>72 14 Q

    /s 20 string def
    (  ) show
    currentlinewidth s cvs show ( ) show
    currentlinecap s cvs show ( ) show
    currentlinejoin s cvs show ( ) show

    0 setlinecap 0 setlinejoin
    77 8.5 72 8.5 DL

    0 Cg EP

and it prints `0.4 1 1' with the two lines in a ps2pdf PDF at

    720.25 8374.25 m 770.25 8374.25 l S
    720.25 8334.25 m 770.25 8334.25 l S

So setting cap and join to 0 doesn't affect the 0.25 offset.

You mentioned switching from `s' to `S' to `closepath' the line.  How
does closing the path affect the rendering of a simple straight line
that's not a `circuit'?

Whilst editing the grops PostScript I noticed

    % x y x y -
    /DL{ SN moveto SN lineto stroke }bind def

and wonder what SN was doing.

    % x y - x' y'
    /SN{
    transform
    .25 sub exch
    .25 sub exch
    round .25 add exch
    round .25 add exch
    itransform
    }bind def

It seems odd to subtract 0.25 before rounding to the nearest integer
rather than 0.5, but perhaps it's accomodating the transform?

Another edit of the PostScript to see the values;  the output is in the
comments.

    .4 LW
    77 4.5 72 4.5 DL
    /F0 10/address@hidden SF<20>72 14 Q

    /space { (  ) show } def
    /s 20 string def
    /printpair { exch  s cvs show  (,) show  s cvs show } def
    space
    1 1 transform printpair space  % 1.20228,1.0135
    77 4.5 SN printpair space      % 76.7291,4.52372
    72 4.5 SN printpair space      % 71.7386,4.52372

    0 Cg EP

I'm now a bit bemused and confused from staring at it all for a while.
I don't think I can hassle the GhostScript folks yet because

    $ cat simple.ps
    %

    0.4 setlinewidth 0 setlinecap 0 setlinejoin
    100 100 moveto 100 0 rlineto stroke
    showpage
    $
    $ ps2pdf simple.ps
    $ qpdf -qdf simple.pdf simple.qdf
    $

leaves simple.qdf spot on:

    stream
    q 0.1 0 0 0.1 0 0 cm
    /R7 gs
    4 w
    0 G
    1000 1000 m
    2000 1000 l
    S
    Q
    endstream

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy



reply via email to

[Prev in Thread] Current Thread [Next in Thread]