linewidth doesn't change bounding box

[jeapostrophe]

#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.

[rfindler]

I don't think it should change the bounding box.

[jeapostrophe]

I hope you agree that the flat points looks bad and the user doesn't really want it.

If linewidth doesn't change the box, then I feel like there should be (and maybe there is?) a function called fix-bounding-box so I can write (fix-bounding-box (linewidth 5 (outline-flash 100 105))) and have the full shape be drawn. Otherwise, I don't know how to draw things properly without doing more non-algebraic work of rendering, looking at it and guessing how much extra space I need.

That said, I don't understand why you think that it shouldn't change. In particular, the bounding box IS changed (OR pict doesn't mean "the rectangle that the drawing fits inside" when it uses the term bounding box in contradiction to other standard uses).

Consider this program:

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

(define (test lw)
  (define R (colorize (rectangle 50 50) "red"))
  (define F (outline-flash 100 105))
  (define L (linewidth lw F))
  (define O (frame L))
  (define C (vc-append R O R))
  (hc-append R C R))

(test 1)
(test 20)

You can clearly see that L is drawing outside of its bounding box.

Can you debug me? Is there something that you know about for the long history of pict that this would mess up?

[rfindler]

that's not what the bounding box means for picts. What it really means is "things line up here". I think that a change like this would break pretty much every talk I've written that uses linewidth (but perhaps in subtle ways).

I think that if you want to change the bounding box and you want to change the line widths, then call linewidth and call inset.

Also, I think that you'd probably end up reimplementing a large part of the drawing toolkit to get this functionality (the part that computes where curves are drawn).

[jeapostrophe]

I agree that it is very not backwards compatible and that is bad.

I agree that inset is the function to call to manually adjust things, but I don't like that you have to guess what the values to put in.

In particular, I don't like that file/convertible doesn't a pict into a bitmap that actually shows the whole thing, since it looks at the "bounding box" rather than "what will actually be drawn". This means DrRacket can't be used to design the graphic unless you plop in the middle of a giant box and it means that you can't easily save the pict to a file (because you'll get this clipping.)

Now regarding your last comment about reimplementation, do you mean to discover the real bounding box?

[rfindler]

On Sat, Dec 31, 2016 at 8:53 AM, Jay McCarthy ***@***.***> wrote: Now regarding your last comment about reimplementation, do you mean to discover the real bounding box?

Yes. I think it would make sense to add a function, perhaps called `fit-to-drawing` or something that computed a new bounding box based on what is actually drawn in the pict. I think you'd need to involve the backend drawing library since you don't want to reimplement font drawing, for example (and different backends draw different curves in slightly different ways too, iirc).