<div dir="ltr">Seems like it would be better to consistently use one device unit rather than the maximum of one device unit and one unit in the CTM.<div><br></div><div>The zero stuff is a real pain but I suspect trying to fix this in Cairo (and also support hairlines on other output devices) will be a lot of work.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 7:10 PM Rick Yorgason <<a href="mailto:rick@firefang.com">rick@firefang.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Apologies for the delay. Here's the promised updated patch.</p>
<p>The difference is now it considers the minimum size of both the
canvas and the printer instead of just the canvas, zero-width
strokes count as hairlines (although Cairo still seems to be
culling strokes from getting to this function — that's a separate
bug) and the documentation was updated for clarity.<br>
</p>
<p>Cheers,</p>
<p>-Rick-<br>
</p>
<br>
<div class="m_-909196513678428700moz-cite-prefix">On 2018-10-19 12:12, Rick Yorgason
wrote:<br>
</div>
<blockquote type="cite">
That shouldn't be. See page 675 of the Postscript Language
Reference:
<a class="m_-909196513678428700moz-txt-link-freetext" href="https://www.adobe.com/content/dam/acom/en/devnet/actionscript/articles/PLRM.pdf" target="_blank">https://www.adobe.com/content/dam/acom/en/devnet/actionscript/articles/PLRM.pdf</a><br>
<br>
<blockquote type="cite">A line width of 0 is acceptable, and is
interpreted as the thinnest line that can be rendered at device
resolution—1 device pixel wide. However, some devices cannot
reproduce 1-pixel lines, and on high-resolution devices, they
are nearly invisible.</blockquote>
<br>
-Rick-<br>
<br>
<br>
<div class="m_-909196513678428700moz-cite-prefix">On 2018-10-19 09:27, Bill Spitzak
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hairlines are not always 1 pixel wide. For
Postscript setting the line width to 0.0 gives you a hairline
that seems to be about 1/150" which is quite a few pixels on
modern printers, and was > 1 even on the first Apple
Laserwriter.</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Oct 19, 2018 at 6:21 AM Rick Yorgason
<<a href="mailto:rick@firefang.com" target="_blank">rick@firefang.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It looks
like you're right about the device units. In cases where the
<br>
canvas DPI is lower than the device DPI, the "smallest
printable line" <br>
is 1, as in my original patch (because ExtCreatePen only
accepts <br>
integral pen widths), but when the canvas DPI is higher, the
"smallest <br>
printable line" is <br>
`_cairo_matrix_transformed_circle_major_axis(stroke_ctm_inverse, 1.0)`.<br>
<br>
I haven't looked any further into what's culling zero-width
lines yet. <br>
For now, I'm focusing on the "use PS_COSMETIC for smallest
printable <br>
lines" patch, which I believe should be separate from the
"allow <br>
printing zero-width lines" patch.<br>
<br>
Tomorrow I'll post a new patch based on the feedback I've
received so far.<br>
<br>
-Rick-<br>
<br>
<br>
On 2018-10-19 00:56, Adrian Johnson wrote:<br>
> There were some patches to fix the culling on narrow
lines on vector<br>
> surfaces:<br>
><br>
> <a href="https://gitlab.freedesktop.org/cairo/cairo/commit/b1192beac7c5b56a8ff356d20af5ebfb65404109" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/cairo/cairo/commit/b1192beac7c5b56a8ff356d20af5ebfb65404109</a><br>
><br>
> <a href="https://gitlab.freedesktop.org/cairo/cairo/commit/bec8c7508ebc0f69266f9aebe9903539391c519b" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/cairo/cairo/commit/bec8c7508ebc0f69266f9aebe9903539391c519b</a><br>
><br>
> Those patches should allow zero width lines. I'm not
sure what else<br>
> could be preventing zero width lines from getting
through to the win32<br>
> print surface.<br>
><br>
> You code that sets the cosmetic flag is not checking
the line width in<br>
> device units. The StrokePath() is called in user
coordinates so that the<br>
> line width will be in user coordinates. The reason
emitting the path in<br>
> device space and stroking in user space is demonstrated
here<br>
> <a href="https://cairographics.org/tutorial/#L2linewidth" rel="noreferrer" target="_blank">https://cairographics.org/tutorial/#L2linewidth</a><br>
><br>
> To check if the line width is < 1 device unit you
would need to do<br>
> something line in the second commit above to find the
line width in user<br>
> space.<br>
><br>
><br>
> On 19/10/18 07:32, Rick Yorgason wrote:<br>
>> Sure enough, Cairo seems to be culling zero-width
lines somewhere, so it<br>
>> doesn't matter whether or not I check for zero
here.<br>
>><br>
>> For now, I propose that I get rid of the zero-check
in my patch, so<br>
>> anything <= 1 device unit is drawn with a
PS_COSMETIC pen. This value<br>
>> gets rounded to an integer, so this approach is
consistent with the<br>
>> definition of a hairline being the smallest thing a
printer can print.<br>
>><br>
>> In the long run, it would be nice to track down
where Cairo is culling<br>
>> zero-width lines and allow them through, as I
believe postscript and pdf<br>
>> both treat zero-width lines as hairlines.<br>
>><br>
>> -Rick-<br>
>><br>
>><br>
>> On 2018-10-18 12:09, Bill Spitzak wrote:<br>
>>> I suspect there is code in Cairo that assumes
zero-width strokes are<br>
>>> invisible, so it may be difficult to fix it for
only this device.<br>
>>><br>
>>> The main reason for using zero rather than any
other number is that it<br>
>>> survives scaling, which is pretty important for
a magic value.<br>
>>><br>
>>> On Thu, Oct 18, 2018 at 11:12 AM Rick Yorgason
<<a href="mailto:rick@firefang.com" target="_blank">rick@firefang.com</a><br>
>>> <mailto:<a href="mailto:rick@firefang.com" target="_blank">rick@firefang.com</a>>>
wrote:<br>
>>><br>
>>> Including zero-width strokes makes sense
to me. After all, true<br>
>>> hairlines are supposed to act as though
they're zero-width.<br>
>>><br>
>>> The reason I implemented it this way it's
because I was worried<br>
>>> about two use cases:<br>
>>><br>
>>> 1) Some applications might rely on
zero-width lines being<br>
>>> invisible. (Imagine an artist who selects
all the lines he wants<br>
>>> to hide and changes their line width to
zero.)<br>
>>><br>
>>> 2) Maybe some CNC machines rely on
zero-width lines? PS_COSMETIC<br>
>>> lines are always 1 unit wide, so there
would be no way to send<br>
>>> zero-width lines to the printer any more.
This seems unlikely to<br>
>>> be a problem, but it's possible.<br>
>>><br>
>>> (1) can be fixed by the calling
application, and (2) isn't likely<br>
>>> a real problem, and if we include
zero-width strokes it would make<br>
>>> it easier for developers to make true
zero-width hairlines (since<br>
>>> they don't need to know the target
device's minimum unit size), so<br>
>>> I'm down for it.<br>
>>><br>
>>> -Rick-<br>
>>><br>
>>> On October 18, 2018 9:10:07 AM PDT, Carl
Worth <<a href="mailto:cworth@cworth.org" target="_blank">cworth@cworth.org</a><br>
>>> <mailto:<a href="mailto:cworth@cworth.org" target="_blank">cworth@cworth.org</a>>>
wrote:<br>
>>><br>
>>> On Wed, Oct 17 2018, Rick Yorgason
wrote:<br>
>>><br>
>>> With this patch, I can use
Inkscape to set my stroke width<br>
>>> to 0.001" and it will cut through
the material as expected.<br>
>>><br>
>>><br>
>>> If we're going to have a magic value
here, I think I'd be much happier<br>
>>> to have 0 be the magic value.<br>
>>><br>
>>> (I know that your code isn't actually
making 0.001" be magic, but a<br>
>>> whole range of values. I think I would
really prefer to have that range<br>
>>> include rather then exclude 0.0.)<br>
>>><br>
>>> Does anyone see any reason why a
stroke width of 0 shouldn't be treated<br>
>>> this way?<br>
>>><br>
>>> I think that would make a much better
way to be able to document<br>
>>> this. ("Use a value of 0 to get a
PS_COSMETIC pen which is useful when<br>
>>> targeting devices such as laser
cutters".)<br>
>>><br>
>>> And speaking of documentation, it
seems this patch should also be<br>
>>> touching up the documentation, such as
in cairo_set_line_width?<br>
>>><br>
>>> I know the code is specific to the
Windows backend, but I think it's<br>
>>> reasonable to put a backend-specific
note into the general documentation<br>
>>> in a case like this.<br>
>>><br>
>>> -Carl<br>
>>><br>
>>><br>
>>> --<br>
>>> Sent from my Android device with K-9 Mail.
Please excuse my brevity.<br>
>>> --<br>
>>> cairo mailing list<br>
>>> <a href="mailto:cairo@cairographics.org" target="_blank">cairo@cairographics.org</a>
<mailto:<a href="mailto:cairo@cairographics.org" target="_blank">cairo@cairographics.org</a>><br>
>>> <a href="https://lists.cairographics.org/mailman/listinfo/cairo" rel="noreferrer" target="_blank">https://lists.cairographics.org/mailman/listinfo/cairo</a><br>
>>><br>
>><br>
>><br>
<br>
-- <br>
cairo mailing list<br>
<a href="mailto:cairo@cairographics.org" target="_blank">cairo@cairographics.org</a><br>
<a href="https://lists.cairographics.org/mailman/listinfo/cairo" rel="noreferrer" target="_blank">https://lists.cairographics.org/mailman/listinfo/cairo</a></blockquote>
</div>
</blockquote>
<br>
<br>
<fieldset class="m_-909196513678428700mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</div>
</blockquote></div>