[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [groff] gropdf(1) Has Ugly Thick Lines by Default.
From: |
Deri |
Subject: |
Re: [groff] gropdf(1) Has Ugly Thick Lines by Default. |
Date: |
Sat, 28 Jul 2018 18:15:03 +0100 |
On Saturday, 28 July 2018 14:37:14 BST Ralph Corderoy wrote:
> I think grops should copy grops's choice of default line width.
> And the differences in coordinates seem odd. Even if they're correctly
> compensating for line-cap differences, should those differences exist?
Hi Ralph,
I agree. grops.cpp has a DEFAULT_LINEWIDTH set to 40 (ems/1000). So I will
include 0.4 w when I set up the graphics environment at the start of each new
page.
I have recently (during the recent discussion on changing linecaps within pic)
realised I should be using "S" for stroking rather than "s", so the path is
closed. This prevented the linecaps being changed when using the example given
and gropdf.
As regards the difference in coordinates, I am a bit baffled. The groff
intermediate output for the first line is:-
x T pdf
x res 72000 1 1
x init
x F -
p1
x F -
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:-
4 LW 85.33 4.5 72 4.5 DL
Which seems correct. 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. It
appears that the difference in coordinates is being introduced by conversion
from postscript to pdf!
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 wondered whether ghostscript is looking at my
default printer and adjusting for printable area, but I have not tested this.
Finally, the unnecessary switching between text and graphic mode you have
noted, I believe this is because I have wrongly assumed that the presence of
an absolute positioning command was a precursor to receiving text, so it
switches mode, I shall think some more on this. :-(
Cheers
Deri