You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Almost a year ago I asked about the details of perpendicularmark function on Forum.
Since no one replied there, I got in contact with Philippe Ivaldi, and here is the excerpt from it:
I understand that perpfactor linearly scales the size of the mark,
while 'sqrt(1 + linewidth(p)) - 1' stands for some kind of margin. At
the first look, I couldn't get the logic behind 'sqrt(1 + x) - 1'
expression, but then I realized it must be like this: sqrt(1 + x) - 1
~ 1 + x/2 - 1 = x/2 => 'half of linewidth'.
If that is correct, was there any particular reason for not using just linewidth(p)/2?
Hi Ivan,
Thank you for the interest you port to this module.
I can't give you a good feedback to yours proposals because I coded this
module nine years ago and stop using Asymptote after this date.
For question iii, I don't really remember why I used sqrt(1 + linewidth(p)) - 1
instead of linewidth(p)/2…
Perhaps for a kind of offset when linewidth(p) increase ?
Do your best :)
So, I doubt that "sqrt(1 + x) - 1" actually stands for approximation of "x / 2", and started to test it and compare it with possible changes/improvements...
Here is the latest what I have:
import geometry;
unitsize(20mm);
void perpendicularmark_new(picture pic = currentpicture, point z,
explicit pair align,
explicit pair dir = E, real size = 0,
pen p = currentpen,
margin margin = NoMargin,
filltype filltype = NoFill)
{/*<asyxml></code><documentation>Draw a perpendicular symbol at z aligned in the direction align
relative to the path z--z + dir.
dir(45 + n * 90), where n in N*, are common values for 'align'.</documentation></function></asyxml>*/
p = squarecap + miterjoin + p;
if(size == 0) size = perpfactor * 3mm + linewidth(p) / 2;
frame apic;
pair d1 = size * align * unit(dir) * dir(-45);
pair d2 = I * d1;
path g = d1--d1 + d2--d2;
g = margin(g, p).g;
draw(apic, g, p);
if(filltype != NoFill) filltype.fill(apic, (relpoint(g, 0) - relpoint(g, 0.5)+
relpoint(g, 1))--g--cycle, p + solid);
add(pic, apic, locate(z));
}
real opacity_level = 0.4;
real s = 0.4;
for (int i = 0; i < 15; ++i) {
dot((i, 0), UnFill);
perpendicularmark((point) (i, 0), NE, red + linewidth((1 + s)^i * linewidth()) + opacity(0.4));
perpendicularmark_new((point) (i, 0), NE, green + linewidth((1 + s)^i * linewidth()) + opacity(0.4));
if (i == 0) continue; // do not draw twice
dot((-i, 0), UnFill);
perpendicularmark((point) (-i, 0), NE, red + linewidth((1 - s)^i * linewidth()) + opacity(0.4));
perpendicularmark_new((point) (-i, 0), NE, green + linewidth((1 - s)^i * linewidth()) + opacity(0.4));
}
You can see what happens in "thick region" corresponding to red color:
Inner "empty square" gets smaller and smaller...
...and once it disappear, things get bad onwards.
One might say that is veeery thick and no one will do something like that, but it would be convenient to have both clean code and proper geometric explanation for something implemented.
On the other hand, upper implementation (corresponding to green color) keeps that "empty square" of constant size (independent of pen), and does not have issues in "thick region".
I am about to submit Pull request fixing this issue in 15 minutes so you can take it under consideration.
Kind regards, Ivan
The text was updated successfully, but these errors were encountered:
Hi!
Almost a year ago I asked about the details of
perpendicularmark
function on Forum.Since no one replied there, I got in contact with Philippe Ivaldi, and here is the excerpt from it:
So, I doubt that "sqrt(1 + x) - 1" actually stands for approximation of "x / 2", and started to test it and compare it with possible changes/improvements...
Here is the latest what I have:
test_perp.pdf
You can see what happens in "thick region" corresponding to red color:
One might say that is veeery thick and no one will do something like that, but it would be convenient to have both clean code and proper geometric explanation for something implemented.
On the other hand, upper implementation (corresponding to green color) keeps that "empty square" of constant size (independent of pen), and does not have issues in "thick region".
I am about to submit Pull request fixing this issue in 15 minutes so you can take it under consideration.
Kind regards, Ivan
The text was updated successfully, but these errors were encountered: