<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>If it's helpful, I've created a gitlab branch here:
<a class="moz-txt-link-freetext" href="https://gitlab.freedesktop.org/Skrapion/cairo/commit/9c81cdd255cd2553ff99cf11e086f905d577e4a0">https://gitlab.freedesktop.org/Skrapion/cairo/commit/9c81cdd255cd2553ff99cf11e086f905d577e4a0</a><br>
</p>
Thanks for the reviews! Let me know if you would prefer for this to
be based on just the CTM instead of both the CTM and device pixel.<br>
<br>
-Rick-<br>
<br>
<div class="moz-cite-prefix">On 2018-10-29 13:29, Rick Yorgason
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:517aa610-f507-5b01-5653-38ecbdc62546@firefang.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>I think it makes sense to do both, but if we're only going to
have one check, it should be the CTM, like i originally had.</p>
<p>If we only test the device unit, then we run into weird
scenarios. Let's say 1 device pixel is 0.3 CTM units. That means
anything from [0-0.3] units *will* draw as a hairline, but
anything from (0.3-1) will get rounded to 0 and won't draw at
all. (Remember, ExtCreatePen takes the pen width as an integer.)
So 0.3 and 1.0 draw, but 0.5 doesn't.</p>
<p>-Rick-<br>
</p>
<br>
<div class="moz-cite-prefix">On 2018-10-29 10:12, Bill Spitzak
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAL-8oAjhZzV2220cqNeEPYsp9PszxPLBdXpm0yAWpKTyodLh7Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">rick@firefang.com</a><br>
>>> <mailto:<a
href="mailto:rick@firefang.com" target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">cworth@cworth.org</a><br>
>>> <mailto:<a
href="mailto:cworth@cworth.org" target="_blank"
moz-do-not-send="true">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" moz-do-not-send="true">cairo@cairographics.org</a>
<mailto:<a
href="mailto:cairo@cairographics.org"
target="_blank" moz-do-not-send="true">cairo@cairographics.org</a>><br>
>>> <a
href="https://lists.cairographics.org/mailman/listinfo/cairo"
rel="noreferrer" target="_blank"
moz-do-not-send="true">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" moz-do-not-send="true">cairo@cairographics.org</a><br>
<a
href="https://lists.cairographics.org/mailman/listinfo/cairo"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.cairographics.org/mailman/listinfo/cairo</a></blockquote>
</div>
</blockquote>
<br>
<br>
<fieldset
class="m_-909196513678428700mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>