racket / pict Goto Github PK

I'm trying to take a pict I have and flip it horizontally/vertically, but in the docs the only thing I can find that's even kind of related is the rotate function. It appears there's currently no way to flip a pict without converting it to another format first. What I've ended up doing is converting it to a bitmap, then to a flomap, flipping it, converting it back to a bitmap, and then back to a pict. This process is quite slow and messy.

Could flipping a pict be added to the library? It would be very much appreciated.

See: http://drdr.racket-lang.org/33865/racket/share/pkgs/pict-test/tests/pict/main.rkt

#lang racket
(require pict pict/shadow pict/conditional)
(pict-height
   (clip-descent
    (clip-ascent
     (rotate (text "sefsefse") pi))))

Produces

-9.070312500000002

This results in two observable errors:

> (blur
   (clip-descent
    (clip-ascent
     (rotate (text "sefsefse") pi)))
   3/2)
. . initialization for bitmap%: bad argument combination: 51 -6 #f #t
>  (clip-descent
    (clip-ascent
     (rotate (text "sefsefse") pi)))
. . ../../Applications/Racket/racket/collects/racket/contract/private/blame.rkt:156:0: set-clipping-rect: contract violation
  expected: (not/c negative?)
  given: -9.070312500000002
  in: an and/c case of
      the 4th argument of
      (->m
       real?
       real?
       (and/c real? (not/c negative?))
       (and/c real? (not/c negative?))
       void?)
  contract from: (class record-dc%)
  blaming: (unit language@)
   (assuming the contract is correct)

It is one of those questions that comes up periodically and I'll do this soon

Facilities like dc and 2htdp/image being pict-convertible? are currently hard to discover.

@rfindler suggested that it seems like a good idea to add in a guide like overview of pict, which i imagine mentioning:

Combinator like image drawing
Baselines, text, and pict-last and how to use them
pict/convert and its implementations in the main distro
Using pict with scribble

Ill try to add this soon, and would love suggestion as to what else should go in this guide!

Racket 7.0 sometimes uses Type 3 fonts when rendering picts to pdf. The same picts don't use Type 3 fonts in Racket v6.12. This is bad because the sigplan conference publishing team ACM DL will not accept pdfs with Type 3 fonts.

The difference is because v7.0 uses different pango and cairo dylibs --- but I don't know whether those dylibs or racket's use of them is the problem.

Example program:

#lang racket/base
(require pict file/convertible)

(with-output-to-file "pict.pdf" #:exists 'replace
  (λ () (display (convert (text "Hello World") 'pdf-bytes))))

To reproduce:

0. install the poppler library (to get the pdffonts command)
1. run racket example.rkt
2. run pdffonts pict.pdf and look for Type 3 fonts

Example output on Racket 6.12:

$ /Applications/Racket\ v6.12/bin/racket example.rkt
$ pdffonts pict.pdf
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
NGYLUJ+LucidaGrande                  CID TrueType      Identity-H       yes yes yes      5  0

Example output on Racket 7.0:

$ /Applications/Racket\ v7.0/bin/racket example.rkt
$ pdffonts pict.pdf
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
WIOEMU+LucidaGrande                  TrueType          WinAnsi          yes yes yes      5  0
[none]                               Type 3            Custom           yes no  yes      6  0

cc and thanks for helping identify this issue: @LeifAndersen @rfindler

The documentation for lift-above-baseline reads:

"Lifts pict relative to its baseline, extending the bounding box height if necessary."

However the bounding box is not extended if the shift is negative, and the bounding box seems to get smaller on positive lifts:

> (define t (text "O"))
> (pict-height (lift-above-baseline t -5))
14.1328125
> (pict-height (lift-above-baseline t (pict-height t)))
2.53125

However I worry that changing this function to either never extend the bounding box, or to extend it in a more expected way will be completely backwards incompatible. (For example, I know it will probably change the rendering of at least one of my papers).

So I'm thinking to fix this like so:

Have lift-above-baseline not change the bounding box by default (since shrinking the bounding box on a lift seems like nonsense to me), and add an optional flag for it to extend the bounding box on a negative or positive lift.

Does this seem like a reasonable compromise?

The call

(jack-o-lantern 100 50)

gives an internal error:

brush-list% in find-or-create-brush: bad argument combination: 50 'solid

Generics are all the rage, surely pict should join in the fun?

The contract on pict-width doesn't rule out picts with +inf.0 as the width, but it does break various things, including scribble's rendering of picts. Here's one way such a pict can be created. Probably the best thing is to add more checking on functions like inset and also to update the contracts in the docs on functions like pict-width.

> (pict-width (inset (blank 10 10) +inf.0))
+inf.0

#lang racket/base
(require pict pict/flash)
;; Looks great
(linewidth 1 (outline-flash 100 105))
;; Has flat points
(linewidth 5 (outline-flash 100 105))

I tried to fix this but got really lost. I initially thought the problem would be in outline-flash, so I racket-ified it. I'll push that change, but feel free to revert it if it is too racy.

Pict has adjuster functions linewidth and linestyle to adjust the properties of the outline of a pict, and colorize which changes either the fill color or both the fill color and outline color depending on which ones are not specified (as far as I can tell). Is there a way to change only the outline color of an existing pict? To me it feels more "functional" to compose line styles and colors with (linewidth <style> <pict>) than to specify #:border-color and #:color keyword arguments for each kind of function that creates new picts.

Using a negative argument to scale exposes a violation of the contract on set-clipping-rect blaming (unit language@). I haven't found the definition of language@, so I hope this is the right repository. The error message is essentially the same as with #12.

The following sequence of interactions in DrRacket illustrates the problem:

> (require pict)
> (define p (scale (blank 1 1) -1 1))
> p
../../Applications/Racket v7.1/collects/racket/contract/private/blame.rkt:347:0: set-clipping-rect: contract violation
  expected: (and/c real? (not/c negative?))
  given: -1
  in: the 3rd argument of
      (->m
       real?
       real?
       (and/c real? (not/c negative?))
       (and/c real? (not/c negative?))
       void?)
  contract from: (class record-dc%)
  blaming: (unit language@)
   (assuming the contract is correct)

The same interactions work at the racket REPL; trying to draw the pict seems to trigger the error.

When typesetting code that uses box-drawing characters, characters are not always aligned properly.
That seems to be the case only when actually coloring code (i.e., the are color changes involved); if I typeset things as strings, everything is aligned.

In DrRacket running

Welcome to DrRacket, version 6.6.0.5--2016-06-15(-/f) [3m].
Language: racket, with debugging; memory limit: 1024 MB.
> (require pict/convert)
> pict-convertible?

Results in the error:

?: access disallowed by code inspector to unexported variable from module: "/Users/dan/racket/dev/racket/racket/share/pkgs/pict-lib/pict/private/pict.rkt" in: pict-convertible?

The same code, however, works correctly if entered in DrRacket's definitions window or run in the command line Racket repl.

This means that clipping the ascent and descent can result in a negative height.

> (pict-ascent (shadow-frame (arrow 3/2 2)))
41 1/2
> (pict-descent (shadow-frame (arrow 3/2 2)))
66.0
> (clip-descent (clip-ascent (shadow-frame (arrow 3/2 2))))
. . ../../Applications/Racket/racket/collects/racket/contract/private/blame.rkt:156:0: set-clipping-rect: contract violation
  expected: (not/c negative?)
  given: -4.5
  in: an and/c case of
      the 4th argument of
      (->m
       real?
       real?
       (and/c real? (not/c negative?))
       (and/c real? (not/c negative?))
       void?)
  contract from: (class record-dc%)
  blaming: (unit language@)
   (assuming the contract is correct)

In the pict/tree-layout docs, the tree-edge function is specified as taking a tree-layout?, which in turn is defined to be #f or the output of the tree-layout function. However, the tree-edge contract given in pict/tree-layout.rkt is not sufficiently permissive to allow #f as an input:

> (tree-edge #f)
  tree-edge: contract violation
  expected: tree-layout?
  given: #f
  in: the 1st argument of
      (->* (tree-layout?)
           (#:edge-color (or/c string?
                               (is-a?/c color%)
                               (list/c byte? byte? byte?))
            #:edge-width (or/c 'unspecified real? #f))
           tree-edge?)
  contract from:
      <pkgs>/pict-lib/pict/tree-layout.rkt
  blaming: anonymous-module
   (assuming the contract is correct)
  at: <pkgs>/pict-lib/pict/tree-layout.rkt:20.10

The practical consequence is that this appears to prevent the creation of a binary-tree-layout with one or more individually customized edges.

The immediate cause is that the tree-layout? given as first input in the contract is the struct type predicate from private/layout.rkt, and not the more permissive _tree-layout? function available to client code. Making the input be _tree-layout? does fix the immediate problem and allow tree-edge to take #f; however, naive-layered and binary-tidier fail to render trees created that way:

> (define (complete d)
    (cond
      [(zero? d) #f]
      [else (define s (complete (- d 1)))
            (tree-layout (tree-edge #:edge-color "red" s) s)]))
> (naive-layered (complete 4))
. . ../../Applications/Racket v7.1/collects/racket/private/kw.rkt:1281:57: pin-line: contract violation
  expected: pict-path?
  given: #f
  in: the 4th argument of
      (->* (pict-convertible?
             pict-path?
             (-> pict? pict-path? (values number? number?))
             pict-path?
             (-> pict? pict-path? (values number? number?)))
           ((or/c #f number?)
            (or/c #f string?)
            boolean?
            #:style (or/c #f symbol?))
           pict?)
  contract from:
      <pkgs>/pict-lib/pict/private/utils.rkt
  blaming: <pkgs>/pict-lib/pict/private/main.rkt
   (assuming the contract is correct)
  at: <pkgs>/pict-lib/pict/private/utils.rkt:78.4
> (binary-tidier (complete 4))
. . Repos/pict/pict-lib/pict/private/tidier.rkt:88:9: match: no matching clause for #f

The hv-alternating function does correctly render the resulting trees.

I love Functional Graphics and pict! I would love to combine pict with a constraint-based sizing and layout engine. Has there been any exploration of this? I would like to build something like Alan Borning's ThingLab which was inspired by Ivan Sutherland's Sketchpad. I'm imagining that doing it elegantly would require being able to provide an external environment (computed by the constraint engine) at render time which would override individual size and position information in the tree of pict, but perhaps there are other ways of doing it.

The erroneous expression (linewidth (disk 10) 5) raises the following error: pict-convert: expected argument of type <pict-convertible>; given: 5.

The docs for typeset-code say this:

• (code:comment s ...) — produces a comment block, with each s on its own line, where each s must be a string or a pict.

But on Racket 7.2.0.7 this program makes a pict with the "H" and the "I" on the same line:

#lang racket/base
(require pict/code)
(code (code:comment "H" "I"))

Should the docs be changed, or the implementation?

This program should probably produce something that looks like (ellipse 80 60) looks, instead of crashing.

#lang racket
(require pict pict/snip)
(scale (new pict-snip% [pict (ellipse 40 30)]) 2)

in the documentation for pict finders:

If find is a list, then the first element of find must be within pict, the second element of find must be within the second element, and so on.

no list has been mentioned other than find, so "within the second element" has no clear referent. likewise "and so on" is unclear because the two given items are not clearly parallel ("must be within pict" versus "must be within the second element")

more minorly there is also a probable typo:

Locates a pict designated by find is within pict.

this would probably read fine without "is", or with the addition of "where"

Since blur draws into a bitmap, it should be backing scale-aware. This program demonstrates the problem:

#lang racket

(require racket/gui/base
         pict
         pict/shadow)

(define bmp (make-bitmap 10 10 #:backing-scale 50))
(define dc (new bitmap-dc% [bitmap bmp]))
(draw-pict (blur (circle 8) 1) dc 1 1)

(define bmp-bytes (make-bytes (* 500 500 4)))
(send bmp get-argb-pixels 0 0 500 500 bmp-bytes #:unscaled? #t)
(define bmp* (make-bitmap 500 500))
(send bmp* set-argb-pixels 0 0 500 500 bmp-bytes)
(show-pict (bitmap bmp*))

It produces the following image as output:

…while a blur implementation that accommodates the current backing scale should produce this image, instead:

This example is obviously intentionally exaggerated, but this issue does mean that when rendering to HiDPI displays, blur will produce bitmaps at less than screen quality.

At least in the docs, the image used for fast-edges and fast-middle is identical.

(This only appears to be in the docs for master, not the stable builds).

https://www.cs.utah.edu/plt/snapshots/current/doc/pict/Animation_Helpers.html?q=fast-edge#%28def._%28%28lib._pict%2Fmain..rkt%29._fast-edges%29%29

For example, see: http://drdr.racket-lang.org/37635/racket/share/pkgs/pict-test/tests/pict/main.rkt

The timeouts seem to be independent of the random seed.

Auto Convert tests, seeds: 665514937, 245310249
See: http://drdr.racket-lang.org/33845/racket/share/pkgs/pict-test/tests/pict/main.rkt
http://drdr.racket-lang.org/33841/racket/share/pkgs/pict-test/tests/pict/main.rkt

Currently face* from pict/face is implemented with lambda/kw from the deprecated mzlib/kw, which is not compatible with #lang racket's keyword arguments.

I hope it would be ok to port pict/face (which actually re-exports the apparently undocumented module texpict/face) to modern Racket, and I would be happy to do that, but I don't know what the compatibility considerations are. If pict/face can't change, it seems important to note the non-standard calling convention in the documentation. (You can work around the current problem by writing e.g. (face* 'worried 'grimace 'frown '#:teeth? #t), where the keyword is quoted as an expression, which wouldn't work if pict/face used #lang racket.)

Additionally, looking at the implementation of face* revealed that only the first three by-position arguments are actually required: whatever the resolution to the keyword issue, this should be corrected in the documentation at the same time.

The cellophane function doesn't appear to work as expected when gradients are used, e.g., in a dc pict.

Example:

#lang racket

(require pict
         racket/draw)

(define (rectangle/2t width height 
                      #:border-width [border-width 1]
                      #:border-color [border-color "black"]
                      #:color-1 [color-1 "white"]
                      #:color-2 [color-2 "black"])
  (dc (λ (dc dx dy)
        (define old-brush (send dc get-brush))
        (define old-pen (send dc get-pen))
        (define gradient
          (make-object linear-gradient%
                       dx dy
                       dx (+ dy height)
                       (list (list 0 (make-object color% color-1))
                             (list 1 (make-object color% color-2)))))
        (send dc set-brush (new brush% [gradient gradient]))
        (send dc set-pen (new pen% [width border-width]
                                   [color border-color]))
        (send dc draw-rectangle dx dy width height)
        (send dc set-brush old-brush)
        (send dc set-pen old-pen))
      width height))

(cc-superimpose (disk 20)
                (cellophane (rectangle/2t 100 100 #:color-1 "green") 0.5))

(cc-superimpose (disk 20)
                (cellophane (colorize (filled-rectangle 100 100) "green") 0.5))

I expected the first image this produces to show a disk under a translucent gradiented rectangle.

The link to 2htdp/image in the first paragraph of https://docs.racket-lang.org/pict/index.html fails with the error 'This page is intended to redirect to the result of a search request. Since you’re reading this, it seems that the redirection did not work.':

The relevant scribble is @racketmodname[2htdp/image #:indirect] at line 23 of https://github.com/racket/pict/blob/master/pict-doc/pict/scribblings/pict.scrbl

permalink https://github.com/racket/pict/blob/29e89754c2d6a59fe56027772e7b5113e8560cef/pict-doc/pict/scribblings/pict.scrbl#L23C47-L23C85

failing link:
https://download.racket-lang.org/releases/8.10/doc/local-redirect/index.html?tag=%28mod-path._.%272htdp%2Fimage.%27%29&version=8.10

Browser: identified on Safari, but is reproducible on Firefox and Chrome on MacOS.

note: @[racketmodname] uses #:indirect- the scribble documentation states "deferred resolution relies on cooperation with the page pointed to by the external-link URL" - because of this I'm not sure if this is a problem with https://docs.racket-lang.org/pict/index.html or a problem with https://docs.racket-lang.org/teachpack/2htdpimage.html

here is a program that unexpectedly produces a blank image:

#lang racket/base
(require pict)
(require racket/math)

(define original-shape (rotate (filled-rectangle 10 100) (/ pi 3)))

(ht-append original-shape (scale original-shape -1 1))

here are two programs, very similar to that one, that have no unexpected behavior:

#lang racket/base
(require pict)
(require racket/math)

(define original-shape (rotate (filled-rectangle 10 100) (/ pi 3)))

(ht-append original-shape original-shape)

#lang racket/base
(require pict)
(require racket/math)

(define original-shape (rotate (filled-rectangle 10 100) (/ pi 3)))

(ht-append (scale original-shape -1 1) (scale original-shape -1 1))

Hi! I'm learning Racket during Advent of Code, and I'm really enjoying how easy it is to create quick visualizations of the problems using Pict. However, I have several times needed to draw arbitrary polygons or paths from a list of xy coordinates, and I was surprised that there's no such function in Pict. I think a general-purpose drawing library should have a function like this (ideally, there should be something equivalent to SVG paths, with Bezier curves and such, but that's a bit more advanced).

Here's a quick function I wrote to do this:

(define (polyline coords #:closed? [closed? #t])
  ; coords: list of xy pairs in the form (cons x y)
  (define min-x (apply min (map car coords)))
  (define min-y (apply min (map cdr coords)))
  (define size-x (- (apply max (map car coords)) min-x))
  (define size-y (- (apply max (map cdr coords)) min-y))
  (define coords-shifted (for/list ([xy coords])
                           (cons (- (car xy) min-x) (- (cdr xy) min-y))))
  (dc (λ (dc dx dy)
        (define old-brush (send dc get-brush))
        (send dc set-brush (new brush% [style 'transparent]))

        (define path (new dc-path%))
        (send path move-to (car (first coords-shifted)) (cdr (first coords-shifted)))
        (for-each (λ (xy) (send path line-to (car xy) (cdr xy))) (rest coords-shifted))
        (cond [closed? (send path close)])

        (send dc draw-path path dx dy)
        (send dc set-brush old-brush)
        )
      size-x size-y))

It would of course need arguments to properly specify the line color and fill style etc. I'm also not sure if a list of pairs is the best way to specify the coordinates (pict seems to deal with x and y separately instead of using 2D vectors).

Do you think that something like this should be included in the library?

Similar to save-image and save-svg-image in 2htdp/image.

Sample code by @zenspider:

#lang racket
(require racket/draw metapict metapict/graph)
         
(set-curve-pict-size 500 500)  ; width and height of image
(ahlength  1.0)                ; size of arrow head 
(define f sin)
(define p
  (with-window (window -12 12 -12 12)             ; xmin, xmax, ymin, ymax
    (draw (draw-arrow (curve (pt -10   0) -- (pt 10  0)))  ; x-axis
          (draw-arrow (curve (pt   0 -10) -- (pt  0 10)))  ; y-axis
          (curve (pt -3 1) -- (pt -2 2))
          (label-rt  "x" (pt 10.2 0))                      ; label for x axis
          (label-top "y" (pt 0 10.2))                      ; label for y axis
          (color "blue" (draw (circle (pt 2 1) 3)))        ; center (2,1) radius 3
          (color "red"  (draw (graph f -10 10 #:samples 100))))))
p ; show pict in repl
;(define (save-pict-as-svg p width height filename [exists 'replace])
;  (define dc (new svg-dc%
;                  [width width]
;                  [height height]
;                  [output filename]
;                  [exists exists]))
;  (send dc start-doc "An SVG Test")  ; a message
;  (send dc start-page)
;  (draw-pict p dc 0 0)
;  (send dc end-page)
;  (send dc end-doc))
;
;  
;(save-pict-as-svg p 300 300 "output.svg")

#lang racket
(require pict/code)
(codeblock-pict
 #<<>>
 #lang racket
1
>>
 )

Errors with

substring: starting index is out of range
  starting index: 5
  valid range: [0, 1]
  string: " "

#lang racket
(require pict/code)
(codeblock-pict
 #<<>>
#lang racket
1
>>
 )

Does not.

Here is a program that draws an arrow and annotates it with lines that mark bounding box positions:

#lang racket
(require pict)

(define (metrics-frame p)
  (define metrics-line (hline (pict-width p) 0))
  (let* ([metrics (rectangle (pict-width p) (pict-height p))]
         [metrics (pin-over metrics 0 (pict-ascent p) (colorize metrics-line "red"))]
         [metrics (pin-over metrics 0 (- (pict-height p) (pict-descent p))
                            (linestyle 'long-dash (colorize metrics-line "blue")))])
    (pin-over p 0 0 (colorize (linewidth 1/4 metrics) "gray"))))

(define p (metrics-frame (panorama (pin-over (metrics-frame (linewidth 2 (hline 40 2)))
                                             36 -4 (metrics-frame (arrowhead 10 0))))))
(send (pict->bitmap (scale (inset p 2 2 2 5) 10))
      save-file "out.png" 'png)

This is the program’s output:

The dashed blue line at the very bottom is the descent-specified baseline of the resulting pict. Its position doesn’t make any sense: both of the original picts’ descents are 0. I took a look at the panorama implementation, but I don’t fully understand all the details, especially since pict uses two different coordinate spaces.

Example:

codeblock-pict renders:

Whereas DrRacket renders:

Where the // line lexes as 'comment and in and to lex as 'other

Using typeset-code on a syntax object representing a vector literal produces mangled output that contains the vector's children represented as syntax objects.

(code #(1 2 3))

I'm getting different results for cc-find on different racket versions. v7.7 seems to be correct, v7.8 seems to be broken, where cc-find yields negative values. Here are the details.

The following script:

#lang racket

(require pict)
(define a (cc-superimpose (rectangle 30 30) (scale (text "A") 2)))
(define b (cc-superimpose (rectangle 30 30) (scale (text "B") 2)))
(define c (frame (rotate (vc-append a b) (- (/ pi 10)))))
(cc-find c a)

A visual run of what it does:

I'm testing this code on different racket versions using racket/racket docker images:

docker run -it --rm -v /path/to/test.rkt:/test.rkt racket/racket:7.7-full racket /test.rkt

The results:

• v7.7-full:

28.72748095188456
19.471365063376922

• v7.8-full, v8.0-full, v8.1-full

-0.19578546302995292
10.200855232128504

NOTE that this result is negative, which does not make sense.

Actually, when I run racket-minimal (e.g. racket/racket:8.1) and install pict manually by raco pkg install pict, the results seem to be consistent for all the racket versions (v7.7 through v8.1), BUT yet another different result:

0.3600829975546702
9.630592828803096