3 ms·

I love the concept of using text to create visuals. It greatly appeals to my sensibilities as a coder. The concept of being able to source control the data seem

I love the concept of using text to create visuals. It greatly appeals to my sensibilities as a coder. The concept of being able to source control the data seems amazing in theory. What I found though was that once a diagram hits sufficient complexity the effort to produce a visual appealing image became too great. I likely could spend more time learning tools like graphviz and mermaid - but I find my time better spent in in more traditional graphic tools (lucid charts, Visio etc). I don't proclaim this to be the great truth on these tools, merely my experience.

sgbeal 6y ago
FWIW, pikchr is not intended to be used to create "marketing materials," but solely for dry/boring technical diagrams (not that that's a bad thing - i'm all for dry/boring diagrams). It certainly excels at simple diagrams but likely won't fit the needs of those creating presentations for their CEOs, CFOs, or most other C's-of-O's. Since it exports to SVG, and the Fossil SCM's new "pikchrshow"[^1] feature allows users to easily preview pikchrs and copy the generated SVG to the clipboard, pikchr becomes a potentially interesting option for generating parts of larger diagrams and importing those parts into one's SVG-capable editor of choice. i've started collecting "pikmoji" from contributors over at https://fossil.wanderinghorse.net/r/pikmojicon https://fossil.wanderinghorse.net/r/pikmojicon, for use in copy/pasting into one's own pikchrs. [^1] = https://pikchr.org/home/pikchrshow https://pikchr.org/home/pikchrshow (full disclosure: i added that feature fossil)
- tveyben 6y ago
  >i've started collecting "pikmoji" from... Hmm - as ‘pik’ means ‘dick’ in danish, i have a hard time imaging with ‘pikmoji’s trying to imagine what they would look like in this time of #MeeToo... Not so long ago there was a thread about avoiding ‘bad’ names in foreign languages, this name clearly Spawn interesting associations in Denmark :-)
vinodkd 6y ago
I agree, and you can see this even with "simple" diagrams. For example, the Pikchr examples page[1] has a SQLite architecture diagram, and if you click through to the source (like the idea of "click to see source" btw), you'll find lines like this: line invis from 0.25*$margin east of last.sw up last.ht \ "Backend" italic aligned ...which is an invible line used to create a label for the box that's vertically aligned. This is the kind of "toil" that adds up to what you describe. Ideally, this should be a feature of the language itself, something like box "label" valigned nw but you cannot anticipate every bit of adjustment users would need to produce a visually appealing image, since that's subjective. PIC has macros[2] that somewhat make this easier, but as things get larger you'd still have the issues you mention, and you're trading one complexity (hand drawing visually appealing picture) for another (maintaining more complicated code for local visual appeal). I dont know if pikchr supports macros (which are more like functions since troff is a full fledged language, and less like svg symbols afaict) 1: https://pikchr.org/home/doc/trunk/doc/examples.md https://pikchr.org/home/doc/trunk/doc/examples.md 2: http://floppsie.comp.glam.ac.uk/Glamorgan/gaius/web/pic-14.html#14.%20Macros http://floppsie.comp.glam.ac.uk/Glamorgan/gaius/web/pic-14.h...
- SQLite 6y ago
  Pikchr author here It is difficult to find the right balance between a simple language that requires "toil" and a less toilsome language that is also more complex and requires more effort to learn and master. I'm very open to new ideas of how to make the Pikchr language less toilsome without a corresponding increase in complexity. Expect improvements to occur. Your suggestions are welcomed I envision Pikchr operating in the same nitch as Markdown. (Indeed, Pikchr was originally designed to augment Markdown-based documentation.) An artificial language like PIC/Pikchr is always going to have a steeper learning curve than a GUI diagram drawing tool, just as Markdown documents are always going to be a barrier to entry for pointy-clicky people who prefer MS-Word or Google-Docs. And yet, Markdown persists and even flourishes. Why is that? If point-and-click really is so much better, why are there so many Markdown technical documents out there? A key advantage of Markdown, which helps it thrive in a point-and-click world, is that it is very simple to learn and requires no proprietary tools. Pikchr is not as simple, though it is simpler (I think) than any other artificial language for graphics that I have encountered, and I've tried to make the Pikchr code as accessible and as easy to integrate as I know how. I'm on a mission to make Pikchr simpler still. Your feedback on how to do that is appreciated.

sgbeal 6y ago

FWIW, pikchr is not intended to be used to create "marketing materials," but solely for dry/boring technical diagrams (not that that's a bad thing - i'm all for dry/boring diagrams). It certainly excels at simple diagrams but likely won't fit the needs of those creating presentations for their CEOs, CFOs, or most other C's-of-O's. Since it exports to SVG, and the Fossil SCM's new "pikchrshow"[^1] feature allows users to easily preview pikchrs and copy the generated SVG to the clipboard, pikchr becomes a potentially interesting option for generating parts of larger diagrams and importing those parts into one's SVG-capable editor of choice. i've started collecting "pikmoji" from contributors over at https://fossil.wanderinghorse.net/r/pikmojicon https://fossil.wanderinghorse.net/r/pikmojicon, for use in copy/pasting into one's own pikchrs. [^1] = https://pikchr.org/home/pikchrshow https://pikchr.org/home/pikchrshow (full disclosure: i added that feature fossil)

tveyben 6y ago
>i've started collecting "pikmoji" from... Hmm - as ‘pik’ means ‘dick’ in danish, i have a hard time imaging with ‘pikmoji’s trying to imagine what they would look like in this time of #MeeToo... Not so long ago there was a thread about avoiding ‘bad’ names in foreign languages, this name clearly Spawn interesting associations in Denmark :-)

vinodkd 6y ago

I agree, and you can see this even with "simple" diagrams. For example, the Pikchr examples page[1] has a SQLite architecture diagram, and if you click through to the source (like the idea of "click to see source" btw), you'll find lines like this: line invis from 0.25*$margin east of last.sw up last.ht \ "Backend" italic aligned ...which is an invible line used to create a label for the box that's vertically aligned. This is the kind of "toil" that adds up to what you describe. Ideally, this should be a feature of the language itself, something like box "label" valigned nw but you cannot anticipate every bit of adjustment users would need to produce a visually appealing image, since that's subjective. PIC has macros[2] that somewhat make this easier, but as things get larger you'd still have the issues you mention, and you're trading one complexity (hand drawing visually appealing picture) for another (maintaining more complicated code for local visual appeal). I dont know if pikchr supports macros (which are more like functions since troff is a full fledged language, and less like svg symbols afaict) 1: https://pikchr.org/home/doc/trunk/doc/examples.md https://pikchr.org/home/doc/trunk/doc/examples.md 2: http://floppsie.comp.glam.ac.uk/Glamorgan/gaius/web/pic-14.html#14.%20Macros http://floppsie.comp.glam.ac.uk/Glamorgan/gaius/web/pic-14.h...

SQLite 6y ago
Pikchr author here It is difficult to find the right balance between a simple language that requires "toil" and a less toilsome language that is also more complex and requires more effort to learn and master. I'm very open to new ideas of how to make the Pikchr language less toilsome without a corresponding increase in complexity. Expect improvements to occur. Your suggestions are welcomed I envision Pikchr operating in the same nitch as Markdown. (Indeed, Pikchr was originally designed to augment Markdown-based documentation.) An artificial language like PIC/Pikchr is always going to have a steeper learning curve than a GUI diagram drawing tool, just as Markdown documents are always going to be a barrier to entry for pointy-clicky people who prefer MS-Word or Google-Docs. And yet, Markdown persists and even flourishes. Why is that? If point-and-click really is so much better, why are there so many Markdown technical documents out there? A key advantage of Markdown, which helps it thrive in a point-and-click world, is that it is very simple to learn and requires no proprietary tools. Pikchr is not as simple, though it is simpler (I think) than any other artificial language for graphics that I have encountered, and I've tried to make the Pikchr code as accessible and as easy to integrate as I know how. I'm on a mission to make Pikchr simpler still. Your feedback on how to do that is appreciated.