If people could share the source along with the diagrams they make, this could be huge for accessibility. I can't count how many times I've been blocked from reading some content just because of all the JPGs and SVGs my screen reader couldn't read. Often they were themselves created with GUI programs, so even the authors couldn't help.
I love this idea, but the practicality of it all does depend a lot on the language used to describe the diagrams. I have seen impressive "single file" LaTeX articles, where the figures were carefully crafted in Tikz, and the source code of the figures was all but readable.
I work on the SVG renderer for Penrose and would love to reach out and see if there's anything we can do to improve this! The renderer is written declaratively in react so it's easy to add supplemental tags or even a more readable DOM hierarchy.
Even nicer would be if people bothered to fill out the `alt` and `title` attributes with details about the image as well as the reason for it being there.
Has the following transcript: [[A concerned pet owner at the front of a row of customers in a veterinarian's office. A tired veterinary assistant performs arbitrage. A pet carrier cage, the sort used to contain a small dog or cat, is on a desk for the vet tech to examine.]] Pet owner: There's something wrong with my dog. Pet owner: He keeps crawling around eating dirt. [[The vet tech carefully removes the dog from its carrier and gently examines it.]] Vet tech: This is a roomba. Pet owner: Well, he's a mix. Pet owner: Probaby some roomba in there. [[The vet tech places the roomba on the desk, probably maintaining a weary forced congeniality though we can't see their face.]] Vet tech: A roomba is not a pet. Pet owner: You're right. It's wrong to keep a beautiful creature like this in a house. [[The pet owner, outside, beneath a tall tree. It looks like an ash, or maybe a beech. There aren't any leaves drawn in the frame so I can't be sure.]] Pet owner: Go! Be free! [[The roomba cheerfully speeds towards the tree]] Roomba: WHIRRR {{Title text: It's probably for the best. Since Roombas are native to North America, it's illegal for Americans to keep them in their houses under the Migratory Bird Treaty Act.}}
So... there's another entire layer of xkcd humor?!? That (at least for this one) isn't even on forums.xkcd? That I've been oblivious to for years? OMG. 2k comics to revisit, or at least to scrape for transcripts? TIL... wow, that's unexpected.
"The Penrose team is based at Carnegie Mellon University, comprising Katherine Ye, Nimo Ni, Dor Ma'ayan, Max Krieger, Rain Du, Josh Sunshine, Jonathan Aldrich, and Keenan Crane. (Emeritus: Jenna Wise and Lily Shellhammer.)"
Lovely project, but "Penrose" is not the best name possible. There will be confusion between diagrams made with Penrose (Penrose diagrams?), and Penrose diagrams:
i’m having trouble finding a gallery of examples that give a sense of the range of different diagrams Penrose can create. anyone know if there is such a thing?
I use Penrose diagrams all the time for my research and was hoping to see exactly this. I'm thinking of contacting the developers and participating in their survey...
It seems this is for mathematical diagrams (X,Y or Venn), am I right? I was wondering if I could make flowcharts, mindmaps or uml diagrams with it. Mermaid.js is nice but limited.
Yes, there is so much potential to integrate diagramming and recent work on constraint solvers including SAT solvers, but also very difficult to make such systems usable and convenient. There is a lot of hackery in graphviz that seems difficult to recreate in a general context. It would help if graphviz could be brought up to date or moved to a better environment for doing new work.
Because the style doesn't know about that. Penrose is inherently an interactive constraint solver and you need to supply such implicit assumptions for a visually pleasing result. At the first glance I guess `objective centerLabel(...)` will do.
What does the implementation language have to do with anything? Sure one could complain that the program is slow/buggy but I don’t think that has much to do with whether one likes the implementation language or not.
I feel like this is like complaining about tex being written in web or hg being written in python (hg being slow seems a more reasonable complaint).
I think with a program, the proof of the pudding is in the eating
I guess, it would be kinda harder to adapt Haskell to the client-side-only interactive web (but of course, people are trying [1]). Nowadays the availability in the web directly impacts its acceptance so it is not a separate concern.
That's kind of outweighed by the more relevant fact that the people who had the time and inclination to create the software preferred one set of tools, and the preferences of some after-the-fact passerby would obviously not factor into this kind of decision.
