Does it make sense to extend record-dc% (or have another version of a similar kind of class) that can record what happened to the cairo context?
Robby On Sat, May 9, 2015 at 11:37 AM, Jens Axel Søgaard <[email protected]> wrote: > 2015-05-08 20:55 GMT+02:00 Robby Findler <[email protected]>: >> >> I don't know if it helps, but I'm willing to fix all of the existing >> snips to use a new interface that's designed for "special values" >> (which wouldn't ask the values to be able to be saved) or to actually >> finish the implementation of snip%-ness, depending on which is >> appropriate for each. The ones I know about are plot, pict3d, value >> turtles, and frtime's signals. (If you know of more, please let me >> know.) > > > A related problem: picts are displayed in DrRacket via snips. > Consider a pict whose implementation take the underlying Cairo > drawing context and draw on it using an external library via the FFI. > Such a pict will not show up correctly in the DrRacket. > [And it didn't before the recent change either. DrRacket used > a recording-dc to copy the pict value, but record-dc% doesn't > record any drawing done directly to the cairo context]. > > The problem appears in the Racket bindings for Poppler, > which renders pdf files to Cairo drawing contexts. > A particular use case: Converting latex formulas into picts > which can be used as labels in plot. > > https://github.com/soegaard/racket-poppler > > Is there a way to support this type of snip/pict too? > > /Jens Axel > > > > -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAL3TdOOuDJWsKe_BTc1aC4V6mcLvBkr%2B9s2H9CoqU%3DgP4U2qog%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
