Coordinate system

[Metaxal]

The coordinate system is a little cumbersome: it requires both the size of the picture and some additional offsetting via a window.

Wouldn't it be possible, using picts, to get rid at least of the window (if not of the picture size) and center the picture?

[soegaard]

Den ons. 7. aug. 2019 kl. 18.35 skrev Laurent Orseau < notifications@github.com>:

The coordinate system is a little cumbersome: it requires both the size of the picture and some additional offsetting via a window. Wouldn't it be possible, using picts, to get rid at least of the window (if not of the picture size) and center the picture?

The use of coordinate system could be improved. I can't see a quick fix, but perhaps we can improve the setup process. The window describes describes the "logical" coordinate system. The default drawing window could be [-1;1]x[-1;1]. When plotting a graph I would set this to [-10;10]x[-10;10]. This is the coordinate system the mathematical objects live in. That is points, vectors and curves which exist outside picts use coordinates in this logical coordinate system. Picts on the other hand have a width and height and always use coordinates [0;width]x[0;height] (and the y-axis is flipped). Using these coordinates directly is great for placing graphics, but not for plotting. The racket/draw docs calls these "user" coordinates. Finally when the pict is rendered into a drawing context the drawing context also has a coordinate system (the device coordinate system). The idea is that picts can be rendered both to bitmaps and svg (for example). The curve-pict-size sets the width and height in the units of the drawing context. For pdf use points and for bitmaps use pixels. The coordinates are in "logical" coordinates (specified by the window). The function draw converts the objects into picts. It needs to know how to map the logical coordinates into pict coordinates. One solution is to make the setup easier. I.e. make a function that sets both the curve-pict-size and the window at the same time. There are a few such functions in "window.rkt" such as window-from-opposite-corners and window-aspect. What is your use case? /Jens Axel

[Metaxal]

No specific use case right now, but I'm likely to have several use cases in the near future (for writing papers and making presentations).

I understand the use of the two coordinates systems (and it is indeed useful), but you should be able to avoid having to specify the dimensions of the frame and of the window by hand. Just center everything automatically and adapt the bounding box to capture everything.

[soegaard]

Sorry - by use case, I meant a concrete MetaPict example.

But I think I got it now. When drawing nodes it is cumbersome to keep track of the size of the entire diagram. Automatically scaling the resulting image makes sense.

Automatic scaling is not always what you want - if you draw pdfs, then (cm 1) needs to produce
something of length 1cm.

But I have an idea. Maybe I can determine the final bounding box and crop the image to fit snugly around the diagram. I.e. interpret the curve-pict-size as the maximum window.

Would that fit your workflow?

[Metaxal]

I was thinking that by default, if no boundaries are specified (neither math nor frame sizes), the image implicitly extends to infinity in the 4 directions, but the resulting picture just uses the smallest bounding box. If the user specifies a window or canvas size, then crop it to this size. Does that make sense?

…

On Thu, Aug 8, 2019 at 6:45 PM Jens Axel Søgaard ***@***.***> wrote: Sorry - by use case, I meant a concrete MetaPict example. But I think I got it now. When drawing nodes it is cumbersome to keep track of the size of the entire diagram. Automatically scaling the resulting image makes sense. Automatic scaling is not always what you want - if you draw pdfs, then (cm 1) needs to produce something of length 1cm. But I have an idea. Maybe I can determine the final bounding box and crop the image to fit snugly around the diagram. I.e. interpret the curve-pict-size as the maximum window. Would that fit your workflow? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#26?email_source=notifications&email_token=AAMU2HFOK7BPC7W2Q7JR2KDQDRLVLA5CNFSM4IKCIKT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD34MLKA#issuecomment-519620008>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMU2HG47CROZKCX4VV2VSLQDRLVLANCNFSM4IKCIKTQ> .

[soegaard]

The function crop/inked from "crop.rkt" was added to solve this problem.

[Metaxal]

Thanks!
Example extracted from crop.rkt:

#lang racket

(require pict
         metapict/crop)
(crop/inked (disk 20 #:border-width 20))
(pict-width (crop/inked (disk 20 #:border-width 20)))
(crop/inked (frame (crop/inked (cc-superimpose (blank 100 100) (circle 10)))))
(newline)
(crop/inked (frame (cc-superimpose (blank 100 100) (circle 10))))
(newline)
(crop/inked (frame (crop/inked (circle 100))))

(require (only-in metapict aligned smoothed unsmoothed))
(pict-width (crop/inked (aligned    (disk 20 #:border-width 20))))
(pict-width (crop/inked (smoothed   (disk 20 #:border-width 20))))
(pict-width (crop/inked (unsmoothed (disk 20 #:border-width 20))))
 

Or do you have a better example?

[soegaard]

No, these are fine example. Den ons. 14. okt. 2020 kl. 11.29 skrev Laurent Orseau < notifications@github.com>:

…

Thanks! Example extracted from crop.rkt: #lang racket (require pict metapict/crop) (crop/inked (disk 20 #:border-width 20)) (pict-width (crop/inked (disk 20 #:border-width 20))) (crop/inked (frame (crop/inked (cc-superimpose (blank 100 100) (circle 10))))) (newline) (crop/inked (frame (cc-superimpose (blank 100 100) (circle 10)))) (newline) (crop/inked (frame (crop/inked (circle 100)))) (require (only-in metapict aligned smoothed unsmoothed)) (pict-width (crop/inked (aligned (disk 20 #:border-width 20)))) (pict-width (crop/inked (smoothed (disk 20 #:border-width 20)))) (pict-width (crop/inked (unsmoothed (disk 20 #:border-width 20)))) Or do you have a better example? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#26 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADQXROYD4YC77NLZYWGQSTSKVVQBANCNFSM4IKCIKTQ> .

-- -- Jens Axel Søgaard