About a year ago I suggested adding PIC support to the Markdown formatter in Fossil. This has now been accomplished on trunk, using a new PIC implementation that I am calling "Pikchr" (pronounced "Picture"). You can now use the Pikchr markup language to safely insert diagrams into Wiki, Forum posts, Tickets, or anyplace else that Markdown is allowed in Fossil. For example:

arrow right 200% "Markdown" "Source"
box rad 10px "Markdown" "Formatter" "(markdown.c)" fit
arrow right 200% "HTML+SVG" "Output"
arrow <-> down from last box.s
box same "Pikchr" "Formatter" "(pikchr.c)" fit

The diagram above was created by the following 5 lines of Pikchr code inside a standard Markdown "fenced code block" that specifies the language as "pikchr". The extra "center" keyword causes the diagram to be centered on the page.

~~~ pikchr center
arrow right 200% "Markdown" "Source"
box rad 10px "Markdown" "Formatter" "(markdown.c)" fit
arrow right 200% "HTML+SVG" "Output"
arrow <-> down from last box.s
box same "Pikchr" "Formatter" "(pikchr.c)" fit
~~~

Pikchr is implemented as a single file of C code with no dependencies other than the standard C library. The Pikchr project is currently hosted at https://pikchr.org. The code base is stable and mostly completely. Real-world experience and testing are needed, and there is a need for documentation, but we have to release the code to accomplish that, so here we go.

I have kept Pikchr as a separate project with no dependencies in the hope of enticing other projects to adapt Pikchr into their Markdown formatters as well. I recognize that a circa-1980 graphics language will likely meet with skepticism among modern pointy-clicky people. Nevertheless, I think that I can sell the idea once given an opportunity to demonstrate its advantages and capabilities and to work up some documentation. A key observation is that Pikchr is to graphical drawing tools as Markdown is to MS-Word, and yet there is no shortage of people using Markdown.

You can help:

• Try out Pikchr and use it in your own forum posts and/or documentation. Docs for Pikchr do not currently exist (in as much as I want to use Pikchr to write the Pikchr does, and Pikchr as only just now come available) but you can use the legacy-PIC documentation as a starting point. The two systems are mostly compatible.

• Find bugs.

• Translate existing GIF/JPEG diagrams in the Fossil source tree into Pikchr.

• Suggest ways of making Pikchr better.

This has now been accomplished on trunk

Zippy!

Pikchr is implemented as a single file of C code with no dependencies

We wouldn't expect any different. :)

Translate existing GIF/JPEG diagrams in the Fossil source tree into Pikchr.

How about the yEd/SVG diagrams I created for the branching doc and the Rebase Considered Harmful essay? Do we leave those diagrams as-is, or do we dogfood the feature by replacing them?

I'm inclined to view the yEd diagrams as nicer-looking, but this Pikchr language emits SVG, which means we can null out some of the differences with CSS. Still, I wonder whether it's a complete replacement. Can you replicate the swim lane diagram with PIC, for example, or do you need to do something like put one PIC diagram in each row of an HTML table, then futz around with CSS to force the alignment of the nodes on the time axis?

How does this play into Fossil Wiki syntax? We've got one of each in that pair.

Can you replicate the swim lane diagram with PIC,

That was one of my earliest test cases:

scale = 0.8
/* First generate the main graph */
scale = 0.75
Main: [
  circle "C0"
  arrow
  circle "C1"
  arrow
  circle "C2"
  arrow
  circle "C4"
  arrow
  circle "C6"
]
Branch: [
  circle "C3"
  arrow
  circle "C5"
] with .sw at Main.C2.n + (0.35,0.35)
arrow from Main.C2 to Branch.C3 chop

/* Now generate the background colors */
layer = 0
$featurecolor = 0xfedbce
$maincolor = 0xd9fece
$divY = (Branch.y + Main.y)/2
$divH = (Branch.y - Main.y)
box fill $featurecolor color $featurecolor \
    width Branch.width*1.5 height $divH \
    at Branch
box fill $maincolor color $maincolor \
    width Main.width+0.1 height $divH \
    at Main
"main" ljust at 0.1 se of nw of 2nd box
"feature" ljust at 0.1 se of nw of 1st box

Having learned from and improved the language, I suspect I could do better now. The motif of underlining sections of a diagram with different color backgrounds is common enough that I've considered adding specific support for that idea to Pikchr, though I have not done so yet. My idea is to add a new attribute to "box" that is something like "... behind list-of-other-objects". It would be easy enough to do, but I have not done so yet.

A core concept of Pikchr is that it should be (relatively) easy to learn (with forgiving and intuitive syntax) and should do the common things simply and easily. Pikchr does not strive to be the ultimate graphic language. The goal here is to create simple and uncluttered diagrams for technical documentation - not to make marketing literature. To that end, I want to avoid adding unnecessary options. So, for example, you can currently specify "bold" and/or "italic" for text, but no other text options are available. This is on purpose. We want to have a sufficient suite of capabilities to help creators communicate their ideas clearly, but without cluttering up the interface with an endless parade of options. Finding the right balance there is hard. A key point is that Pikchr is not designed to do everything you always wanted to do in a graphics language. It's intent is to create clear and easy-to-write and easy-to-edit and enduring diagrams for technical documentation.

That was one of my earliest test cases:

That's not a swim lane diagram. This is.

So, how do you get the "⑤" bubbles to line up vertically in PIC, for example?

Most likely need some computed coordinates, positioning relative to other positions. Apologies, not remembering enough at the moment to write code.

Challenge accepted:

    $laneh = 0.75

    # Draw the lanes
    down
    box width 3.5in height $laneh fill 0xacc9e3
    box same fill 0xc5d8ef
    box same as first box
    box same as 2nd box
    line from 1st box.sw+(0.2,0) up until even with 1st box.n \
      "Alan" above aligned
    line from 2nd box.sw+(0.2,0) up until even with 2nd box.n \
      "Betty" above aligned
    line from 3rd box.sw+(0.2,0) up until even with 3rd box.n \
      "Charlie" above aligned
    line from 4th box.sw+(0.2,0) up until even with 4th box.n \
       "Darlene" above aligned

    # fill in content for the Alice lane
    right
A1: circle rad 0.1in at end of first line + (0.2,-0.2) \
       fill white thickness 1.5px "1" 
    arrow right 50%
    circle same "2"
    arrow right until even with first box.e - (0.65,0.0)
    ellipse "future" fit fill white height 0.2 width 0.5 thickness 1.5px
A3: circle same at A1+(0.8,-0.3) "3" fill 0xc0c0c0
    arrow from A1 to last circle chop "fork!" below aligned

    # content for the Betty lane
B1: circle same as A1 at A1-(0,$laneh) "1"
    arrow right 50%
    circle same "2"
    arrow right until even with first ellipse.w
    ellipse same "future"
B3: circle same at A3-(0,$laneh) "3"
    arrow right 50%
    circle same as A3 "4"
    arrow from B1 to 2nd last circle chop

    # content for the Charlie lane
C1: circle same as A1 at B1-(0,$laneh) "1"
    arrow 50%
    circle same "2"
    arrow right 0.8in "goes" "offline"
C5: circle same as A3 "5"
    arrow right until even with first ellipse.w
    ellipse same "future"
    text "back online" "pushes 5" "pulls 3 & 4" with .n at last arrow

    # content for the Darlene lane
D1: circle same as A1 at C1-(0,$laneh) "1"
    arrow 50%
    circle same "2"
    arrow right until even with C5.w
    circle same "5"
    arrow 50%
    circle same as A3 "6"
    arrow right until even with first ellipse.w
    ellipse same "future"
D3: circle same as B3 at B3-(0,2*$laneh) "3"
    arrow 50%
    circle same "4"
    arrow from D1 to D3 chop

There is a new construct (not found in legacy-PIC) where you can say things like: "arrow right until even with ...". Very helpful for keeping objects aligned.

Challenge accepted:

Adding this CSS to the resulting SVG element does a pretty decent job of a dark mode conversion:

filter: invert(1) hue-rotate(180deg);

Screenshot: https://fossil.wanderinghorse.net/screenshots/pikchr-dark-mode-1.png

Adding this CSS to the resulting SVG element does a pretty decent job of a dark mode conversion:

A recommendation for the SVG generation: if we simply add another CSS class to the SVG element when skin_detail_boolean("white-foreground") is true, e.g. dark-mode or white-foreground or some such, CSS can do a pretty good job of swapping the SVG's color scheme with a single CSS selector and one style rule:

svg.pikchr.dark-theme {
  filter: invert(1) hue-rotate(180deg);
}

This screenshot shows the CSS-based color flipping in action:

https://fossil.wanderinghorse.net/screenshots/pikchr-dark-mode-2.png

but that implementation relies on a checkbox to tell it whether to activate that style. If the SVG element has an appropriate CSS dark-themed class we can CSS-select on then that decision can be moved to CSS space and be changed/disabled by the skin if desired.

Alternately, and more generically, we can add that class to the body or some other high-level element available on all pages, which would change the selector to:

.dark-theme svg.pikchr { ... }

Which would allow any other elements to adapt similarly (though not necessarily with the same CSS filter values - that could be fine-tuned on a case-by-case basis once the high-level DOM element has a class we can match against).

More on the CSS filter attribute: https://developer.mozilla.org/en-US/docs/Web/CSS/filter

Edit: adding a drop-shadow filter also looks spiffy:

filter: ...as above plus... drop-shadow(16px 16px 10px black);

Re: checkbox, I don’t see why. Make the browser tell you what mode the user selected.

Re: checkbox, I don’t see why. Make the browser tell you what mode the user selected.

Most current browsers have it, but it's currently only in a draft spec. Until it's been around a few years in ratified form, it's too new for my admittedly over-sensitive tastes in terms of widespread client-side availability. (This is the guy who still sticks with strict C89 largely because MSVC never fully supported C99 until the past few-ish years (even though he doesn't use MSVC himself). It's just one of my numerous quirks.)

The checkbox also gives the user a way to quickly try out both options, and tweak their colors if needed, rather than having to change a browser-level config option buried in some browser-specific corner of their preferences.

Next stop: ajaxify it so that the editor doesn't get resized on each round trip and the undo state doesn't get lost. But not today. Probably not today.

it's too new

This whole “dark mode” craze is also new. You aren’t going to find old stable interfaces for querying it.

Compromise: use the CSS value to set the checkbox’s initial state.

Compromise: use the CSS value to set the checkbox’s initial state.

There's no way to do that via CSS but we currently effectively do that: if the skin is defined as "white-foreground" (i.e. is a dark theme) then the checkbox defaults to checked, else unchecked. Whether or not that ends up being a generically useful approach to color flipping remains to be seen, though.

I mean query the CSS state in JS init as part of your planned Ajaxification. You have to be in there anyway to attach an onchange event handler.

I mean query the CSS state in JS init as part of your planned Ajaxification.

The "white-foreground" flag of the skin is not visible in/via CSS. It comes from the skin's details.txt and is used to change (C-side) certain color output in various places, but doesn't otherwise leave a hint we could query in JS or CSS. We can of course uplift that setting's value into JS, like we do with the hash length settings and a few others, but the checkbox state selection would end up being the exact same effect as what we currently do in C. (Even so, it might be useful to have that info available in JS, so i'll add that to the info we export from C. With that info in JS, the JS could tag the body element with a CSS class signifying that this is a dark skin.)

(Still waiting for the firewood.)

https://www.freecodecamp.org/news/how-to-detect-a-users-preferred-color-scheme-in-javascript-ec8ee514f1ef/

https://www.freecodecamp.org/news/how-to-detect-a-users-preferred-color-scheme-in-javascript-ec8ee514f1ef/

Their preferred color scheme is not our basis for comparison, though: the skin is the law (currently, anyway) as far as the color selection goes. Long-term, as the browser-level support for dark mode spreads, we will probably want to look at how that interacts with skins and how skins might need to change to adapt to such a world. (Allowing each user to select which skin to use, while still keeping the configuration of the skin an admin-level permission, is one of my personal itches, but not near enough to the top of the list to put too much thought into just yet. It could probably simply be stored as the skin name in the UI preference cookie, though.)

Wood has arrived. Unloading it can wait until tomorrow. i should have an ajaxified version checked in an online on my hoster in the next few hours (a dog-emptying run is going to interrupt me in about an hour).

It looks like the answer to my question above is, "Yes, the yEd diagrams go away," then.

...once Fossil Wiki syntax gets a method for inserting such diagrams, that is. The alternatives are to leave the yEd diagrams alone, or break this popular doc's URL by recasting it into Markdown form.

I believe that legacy PIC can do

arrow right until even with first box.e - (0.65,0.0)

with its syntax. Per the manual:

If p1 and p2 are positions, then (p1,p2) refers to the point (p1.x,p2.y).

Thus

arrow right to (box.e - (0.65,0.0), last.e)

should do it. It is quite a bit less readable when the new syntax, tough.

Hm. The PIKcher syntax does not accept that, looks like ?

There is only a rule for absolute positioning:

position(A) ::= expr(X) COMMA expr(Y). {A.x=X; A.y=Y;}

And no

position(A) ::= position(X) COMMA position(Y). {A.x=X.x; A.y=Y.y;}

The "Here" position described in the "Describing Locations" would've been useful here.

e.g. line to (XXX.w, Here)

   arrow right to (PL.e, Here) "label"
                         ^^^^
ERROR: no such object

Another problem with separate image files is that they do not play well with dark mode. Witness the Rebase Considered Harmful document in dark mode to see what I mean. Pikchr does not yet deal gracefully with dark mode, but it could, I think. Because the image is generated from a text description, the colors can be exchanged. For cases were the script actually specifies colors, we can translate that into a dark-mode equivalent in HSV space. Fossil already does something similar in response to the "white-foreground" detail in the skins. We just need to do a little more research.

separate image files...do not play well with dark mode

There's a selector in CSS for dark mode, so all that's wanted here is an override to change the colors.

That's one of the beauties of SVG: like HTML, the out-of-the-box presentation is just a default, easily overridden.

PIC may be more hand-composable than SVG, but it's usually a mistake to guess that SVG can't do some given thing. It's the language behind Inkscape, which stacks up fairly well with Adobe Illustrator, Corel DRAW!, etc.

Another problem with separate image files is that they do not play well with dark mode. Witness the Rebase Considered Harmful document in dark mode to see what I mean.

For that particular case, adding this CSS to the surrounding P element does the trick, more or less:

    filter: invert(1);

If the resulting SVG, or its containing element, has some distinct CSS class added to it, skins can easily do that themselves with:

.the-distinct-css-class {
    filter: invert(1);
}

Or apply any other CSS filters which might improve the colors for their skin, like hue-rotate().

For browser support overview, see:

https://caniuse.com/css-filters

Yay! Congratulations.

... Is the fit keyword one of the extensions/differences ?

It feels to me that this is added to fix the claim of

... There is no  way  to  say  ‘‘make  a  box  that  just  fits  around this  text’’ or  ‘‘make this  text  fit  inside  this  circle’’ or ‘‘draw a line as long as this text.’’ ...

mentioned in the legacy manual (Second paragraph from the bottom of page three).

May I propose that we focus on the extensions and differences of Pikchr vs PIC first for the immediate docs ?

The "fit" keyword is an extension, and does as you suggest. I needed for the Pikchr syntax diagrams, such as:

$r = 0.2in
linerad = 0.75*$r
linewid = 0.25

# Start and end blocks
#
box "element-list" bold fit
line down 75% from last box.sw
dot rad 250% color black
X0: last.e + (0.3,0)
arrow from last dot to X0
move right 2in
box wid 5% ht 25% fill black
X9: last.w - (0.3,0)
arrow from X9 to last box.w


# The main rule that goes straight through from start to finish
#
box "element" italic fit at 1/2 way between X0 and X9
arrow to X9
arrow from X0 to last box.w

# The by-pass line
#
arrow right $r from X0 then up $r \
  then right until even with 1/2 way between X0 and X9
line right until even with X9 - ($r,0) \
  then down until even with X9 then right $r

# The Loop-back rule
#
oval "\"\n\"" fit at $r*1.2 below 1/2 way between X0 and X9
line right $r from X9-($r/2,0) then down until even with last oval \
   then to last oval.e ->
line from last oval.w left until even with X0-($r,0) \
   then up until even with X0 then right $r
oval "\";\"" fit at $r*1.2 below last oval
line from 2*$r right of 2nd last oval.e left $r \
   then down until even with last oval \
   then to last oval.e ->
line from last oval.w left $r then up until even with 2nd last oval \
   then left 2*$r ->

My basic strategy is to add stuff as I need it. :-)

Never mind, just look at the pikchr wiki: Changes from BellLabs PIC

It feels to me that this is added to fix the claim of

`... There is no way to say "make a box that just fits around this text"

I recall reading that was because pic had no way to know how troff would format the text.

The same problem appears for Pikchr. The translator has no way of knowing the precise size of the text that SVG will generate. It can only guess. Pikchr makes a crude guess based on the number of characters of the string and the "charwid" and "charht" variables which should contain the average width and height of a single character (in inches). Sometimes the guesses are off. Pikchr underestimates the space needed for wide characters and overestimates the space needed for narrow characters. Witness:

move; box "MMMMMMMMMMMM" fit; move; box "||||||||" fit

But the server-side Pikchr translator does not have access to the CSS that controls the font-family and font-size used by SVG, so a rough guess is as best as it can do, as far as I can tell. If anybody has suggestions on how it can do better, please post a follow-up comment.

https://fossil-scm.org/pikchr

Interestingly, that repository provides a full-fledged example of using the lemon parser which isn't deeply intertwined with sqlite3's internals :-D. That's a much-sought-after rarity.

In pik_lookup_color(), gcc is complaining (via the fossil build) that this c might be used initialized:

https://fossil-scm.org/pikchr/file?ci=tip&name=pikchr.y&ln=2749

Interestingly, that repository provides a full-fledged example of using the lemon parser which isn't deeply intertwined with sqlite3's internals :-D. That's a much-sought-after rarity.

I do wonder if MultiMarkown 6 uses the lemon parser as its code generator https://github.com/fletcher/MultiMarkdown-6/blob/0d12a2ae1a42b55603dd7baa7ccc1c6351776a84/DevelopmentNotes/DevelopmentNotes.txt#L190-L191

I do wonder if MultiMarkown 6 uses the lemon parser as its code generator...

Apparently so:

https://github.com/fletcher/MultiMarkdown-6/blob/0d12a2ae1a42b55603dd7baa7ccc1c6351776a84/Sources/libMultiMarkdown/parser.y

Which begs the question: why don't we use lemon for that purpose?

Because the Markdown parser wasn’t written by drh, but by someone who favors hand-rolled parsers instead. We’d have to rebuild that in terms of lemon.

I tried implementing reStructured Text in terms of lemon and got stuck at tokenization. What constitutes a “token” in such a language? Split at all special punctuation?

Seriously asking, but please, answers on another thread. Leave it rhetorical here.

Congratulations and thank you! I am looking forward to replacing some of my Dia drawings I'm not proud of anyway with Pikchr.

The original documentation (Kernighan's Technical Report #116 and ESR's "Making Pictures With GNU PIC.") left an impression that typical users of the language made heavy use of macros, which proved painful to implement (seeing as they stand outside the grammar and operate purely by text substitution) and makes everything harder to do safely. (dpic even seems to have "upgraded" macros to functions, making them safer and allowing recursive use.) Now I see that it's actually possible to draw nice illustrations without any defines.

it's actually possible to draw nice illustrations without any defines.

That's good because "define macro" one of the features of legacy-PIC that I omitted. :-)

The macro system of the original PIC is the barrier to parsing PIC with a context-free grammar. Without that parsing becomes trivial.

This kind of intermixing of lexing and parsing is pretty normal for these old languages IIRC.

work up some documentation

I found some here and here (warning, Postscript, 195 kB!) and have started going thru it. Comments:

...at it is...

Typo. Gimme a commit bit, and I'll fix this sort of thing without bugging you. :)

Drop loops and the if statement.

I know next to nothing about PIC, but that bothers me.

Rather than add this to Pikchr, what if you hybridize it with TH1 by teaching TH1 the PIC commands, creating a graphic drawing DSL:

  for {set a 0} {$a < 3} {[arrow right]}

That then implies that TH1 docs are enabled, with its consequences.

(That link claims TH1 is a security risk, but is it really? I mean, you can DoS a server by creating an infinite loop, but can TH1 do any actual damage? I thought it was pretty tightly scoped to prevent that; thus the wish for "real" Tcl as a build option, to escape those limitations.)

Pikchr is to graphical drawing tools as Markdown is to MS-Word

...and potentially beyond: this plus Fossil's existing embedded doc features might give an alternate solution to the problem that led you to wish for file locking in Fossil, which is surprisingly difficult to achieve.

About all you need for a minimum viable product is a way to string multiple doc pages together with arrow key navigation. For a great many uses of presentation software, that'll suffice.

From the ESR manual, I don't see that PIC is a good language for railroad diagrams, but maybe you could extend it to provide the necessary features. Splits, mergers, etc.

140 HTML color names (ex: DarkBlue) resolve to numbers which are the corresponding RGB value.

Is that necessary? You should be able to pass color names straight through into the SVG output and have the browser look them up for you.

Classes for AND and OR gates?

If you add that, the only remaining thing I don't see from the standard set of flowchart symbols in PIC is decision diamonds.

A list of other common diagram types along with examples might be good to add. It looks like state-transition diagrams should be easy, for example. Maybe go through a UML cookbook and see how many of those you can mimic, if only to build up a series of test cases.

TH1 ... Heh. Look at the Tklib diagram package. That was my attempt at translating PIC fully into something Tcl'ish.

@drh: A note about the by EXPR, EXPR syntax you did not understand. I believe that is the same as diagram's by E E

Classes for AND and OR gates?

and

Drop loops and the if statement.

The main issue with the loops and conditions, and macros was that they were text subst based, and could be interleaved with the regular PIC commands.

Drop that interleaving, and text subst. Make loops, ifs, macro definitions, and uses proper syntactical constructs which expand in the AST after parsing.

Actually, with that the macros become proper functions/procedures. At that point we can go and write libraries of objects (as sets of procedures). Now we do not need special classes for AND and OR, and other sets of things anymore. This simply goes into a library. Libraries effectively create topic-specific DSLs on top of PIKcher (digital circuits already mentioned. Others: Chemical structures, flow diagrams, swim lanes, interaction diagrams, etc. pp.)

Note/Idea: Allow transforms to be applied to objects (rotate, scale, translate (reposition)). Should actually trivially translate into SVG.

This should make using multiples instances of objects from a library much easier.

The main issue with the loops and conditions <...> was that they were text subst based

Do they have to be text-based? The May 1991 edition of Kernighan's TR 116 lists the if and the for statements among the elements as part of the grammar in appendix A. In my admittedly limited experiments no additional conflicts arose from trying to add

element ::= FOR VARIABLE ASSIGN expr TO expr BY expr DO
  LBRACE element_list RBRACE.
element ::= IF expr THEN
  LBRACE element_list RBRACE ELSE
  LBRACE element_list RBRACE.
element ::= IF expr THEN
  LBRACE element_list RBRACE.

to the grammar.

Did not know that about the legacy PIC.

Note that I proposed pretty much that in the post you replied to. Although in more prose, and extended to the macros as well.

Rather than add this to Pikchr, what if you hybridize it with TH1 by teaching TH1 the PIC commands

pic is a domain specific programming language, so makes more sense to me to add pic's features to pikchr than to replace them by adding pic features to TH1.

Classes for AND and OR gates?

If you add that, the only remaining thing I don't see from the standard set of flowchart symbols in PIC is decision diamonds.

This sounds like trying to extend pikchr to include features of UML. Wouldn't be better to just include SVG output from an UML tool?

Introducing the oh-so-cleverly-named /pikchrshow page:

https://fossil-scm.org/fossil/timeline?r=pikchrshow

It's a quick-and-dirty form-based^misref pikchr editor and renderer to allow those with write- or wiki-write permissions on a repo to experiment with pikchr code. (That can also be done via the wiki editor's Sandbox pseudo-page, but this approach is more streamlined, with no tab-swapping involved.)

There didn't seem to be an appropriate existing file to put this in, so it introduces a new file. Suggestions on where else to put it (which don't introduce a new file) are welcomed.

^misref = as opposed to ajax-based. Yes, yes, that's obviously very disappointing, but the brevity of this implementation was simply too tempting.

1. ^{^ a b} Misreference

I think you forgot to "fossil add" the new file.

I think you forgot to "fossil add" the new file.

Oh, i definitely did. Fixed!

About the /pikchrshow page:

1. Why is access restricted to users with write privileges? Nothing gets written. Surely read privilege is sufficient. Am I missing something?

2. Rendering to a separate browser tab/window while keeping the original form up would be nice. Is that possible? I think that is preferable to having separate "Editor" and "Preview" tabs in the same window, because I prefer to see the source and the rendering at the same time.

About the /pikchrshow page:

Briefly from the phone:

1. Only because that's the pattern we've followed for similar request types, and presumably only users with write permission could make use of the results. We can certainly make it more open, though - there's no compelling reason not to.

2. Not via form, but ajaxification would require very little work and would provide a similar effect, keeping the editor and preview in sync (side by side or above/below, whichever currently fits on the screen, without the need for a separate tab) without the loss of state. Same layout as now, but a smoother experience.

i'm busy for the next couple/few hours with a firewood delivery but will make those changes later on this evening.

... will make those changes later on this evening.

• Permissions: any of WkRead, Read, or ForumRead permit access now. We can completely open it up, with no access checks, if preferred.
• Ajaxification is finished (insofar as any code is ever finished), with the preview laid out to the right or under the editor field, depending on how much screen space is available (the flexbox layout will move the preview around as needed).
• The new JS-side overhead is a whole 1.5kb uncompressed, 0.7kb compressed (cached for a year in bundled mode).
• Swapping between normal colors and "simulated dark theme" is now completely client-side.
• The bright colors for errors (see 2nd screenshot) might be a bit much. Removing that is a 2-line change, if y'all prefer it toned down.
• A dog-emptying side-quest is necessary, so i'm off for a little bit, but will check back later for any change requests.
• i'm currently on the pi, so can't build an x86/64 binary for my hoster to demo it, but here are some screenshots:

Success: https://fossil.wanderinghorse.net/screenshots/pikchr-ajaxified-1.png

Failure: https://fossil.wanderinghorse.net/screenshots/pikchr-ajaxified-2.png

(It needs a tiny bit of margin at the top - will fix that later.)

i'm currently on the pi, so can't build an x86/64 binary for my hoster to demo it...

Remedied:

https://fossil.wanderinghorse.net/r/cwal/pikchrshow

To get a good idea of how the dark-theme simulation looks, copy Richard's example from:

https://fossil-scm.org/forum/forumpost/4588c77880?raw

(only the stuff inside the tilde block), tap the preview button, then toggle the checkbox on and off.

That particular feature is just one suggestion for how to deal with coloring pikchr images in dark themes like Ardoise and Eagle. Without a hack like that, the images may well look fine in whatever skin the site is currently using and then become illegible if the site switches to a skin which uses the opposite white-foreground value.

Alternately, the pikchr renderer could swap colors around based on that setting, but that would require a great deal more code and a hook to allow pikchr to implement that fossil-specific logic.

Alternately... there are probably multple Nth options i'm overlooking.

I just checked in changes to the pikchr logic so that the generated SVG uses "viewbox" instead of an explicit "width" and "height". Then, when the SVG gets wrapped inside of "<div style="max-width:NNNpx;">...</div>" that causes the diagram to be at the correct size until the browser window gets too narrow to view the whole thing, at which point the diagram scales down automatically. This is intended to make Pikchr-generated diagrams mobile-friendly.

Below is a wide diagram. To see the effect in action, drag your browser window larger or smaller.

boxrad=10px
box rad 0 "Markdown" "source" "text" fit
arrow
box "Markdown" "formatter" "(markdown.c)" fit
arrow
box "Remove" "unsafe" "HTML" fit
arrow right 200% "CGI return" above
box "Web Server"
arrow right 200% "HTTP reply" above
box "Browser"
arrow <-> down 50% from 2nd box.s
box "Pikchr" "formatter" "(pikchr.c)" fit

Questions For The CSS/HTML Experts:

1. Did I do this right? Is there a better way?

2. Maybe the /pikchrshow page should use a hard width, rather than a max-width?

Maybe the /pikchrshow page should use a hard width, rather than a max-width?

Taking your code you created and posting it in /pikchrshow, and repeatedly tapping the preview button causes the SVG diagram to grow slightly with each click/push.

Would the hard width preview the resizing?

Would the hard width preview the resizing?

i'm not clear what you mean by that. If we fix the preview width then it will always look the same width, with the exception that scrollbars would appear if the SVG were too big. Currently its width is completely dynamic, which is philosophically pleasing but does have drawbacks in terms of UI appearance.

Mistype...sorry

prevent instead of preview.

If you weren't clear on what I originally meant...

1. Copy Richard's code
2. paste into pikchrShow
3. Click preview x 4 and notice the Rendered SVG display enlarges with each click

BTW, what's a strikethrough for markdown? I thought it was ~~hello~~

what's a strikethrough for markdown?

Near as I can tell in the CommonMark spec, it is "<del>text</del>". Are you familiar with some other Markdown system doing "~~text~~"?

I don't know what implementation jira uses but ~~text~~ is what they do:

https://confluence.atlassian.com/bitbucketserver/markdown-syntax-guide-776639995.html

Github as well:

https://docs.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax

But that doesn't mean you need to go out of your way and put it in. I should have tried HTML <s>.

Fossil Markdown also allows <s>: Demo.

Click preview x 4 and notice the Rendered SVG display enlarges with each click

That's a bug but not one from our code - we don't resize those elements, we just let the flexbox layout do it.

BTW, what's a strikethrough for markdown? I thought it was ~~hello~~

Fossil's doesn't do that but, you can use HTML <s> tags: strikeout.

Taking your code you created and posting it in /pikchrshow, and repeatedly tapping the preview button causes the SVG diagram to grow slightly with each click/push.

i think i just came across this: it would alternate between growing and shrinking. The reason, in my case at least, was the browser adding and removing a scrollbar, which changed the available space on the page a small amount, causing the SVG to shrink and grow as the scrollbars came and went.

Maybe the /pikchrshow page should use a hard width, rather than a max-width?

Good question. i tinkered extensively with the sizes last night in order to try to minimize its "twitching" between side-by-side and above/below layouts, and the diagram like the one above will definitely cause it "twitch" during a preview-fetch because the RHS component will shrink while awaiting the preview (falling back to sbs mode) and then revert to above/below layout when the preview arrives. (That's all assuming your screen is not wider than my modest LCD is.)

Anyway... if we fix the width then we've basically got to live with an above/below layout and/or scrollbars on the preview, but either might not be a bad thing^misref. It is a simple matter of a small CSS tweak to force it into a permanent above/below layout without fixing the width, and that might be a better approach. i'll tinker with that and check it in if it seems to make sense.

Would you prefer the preview above or below the editor? Above would seem to look nicer but it will also cause more "twitching" as the editor gets pushed up and down as the preview gets refreshed (unless we fix it's size, in which case we need to accept that large previews might get scrollbars).

Opinions from all on all of the above are more than welcomed. In the meantime, i'll tinker with a few layout variants.

^misref = there's a long-standing bug in Chrome which breaks scrolling of elements which are embedded within a fieldset, so i'll need to restructure some HTML to avoid the use of a fieldset on the preview. A fieldset is currently used to add the label to the top of the preview, but that effect is easily accomplished with other HTML.

1. ^{^ a b} Misreference

Maybe the /pikchrshow page should use a hard width, rather than a max-width?

Okay, this is both unexpected and kind funny, possibly even useful:

If we simply switch pikchrshow to an above/below layout, without fixing any widths, the preview's max width is the window width and the SVG gets scaled down to fit if needed. Screenshot:

https://fossil.wanderinghorse.net/screenshots/pikchr-autoshrink-1.png

i've just checked that in because that might be the ideal solution... except maybe on phones:

https://fossil-scm.org/fossil/info/2dd0a40e599676c4

Let me know what you think about the auto-shrinking. It was a happy(?) accident, not intentional. (Edit: Richard's description of the change should have prepared me for it, but in my joy i had forgotten that detail!)

i've just checked that in because that might be the ideal solution... except maybe on phones:

Chrome's dev tools (i keep forgetting) have a way to simulate mobile devices, making this easy to try out. At 690 pixels wide, that wide diagram is still fairly legible:

https://fossil.wanderinghorse.net/screenshots/pikchr-autoshrink-2.png

Flipping that to landscape, at 865 pixels, leaves it completely legible.

If y'all are happy with that approach, i'm happy with it. If not, suggestions are welcomed.

Haven't tried on the iphone yet, but in the browser, it's great. It solves the other problem I was sloppily explaining.

Yes to under/over layout.

Haven't tried on the iphone yet, but in the browser, it's great. It solves the other problem I was sloppily explaining.

Haven't yet tried it from the phone, but on my tablet - a mid-range Samsung Galaxy A6 - it looks quite nice:

https://fossil.wanderinghorse.net/screenshots/pikchr-tablet-ff-1.png

(It is my deepest desire to live long enough to see all browsers on all platforms align checkboxes and their neighboring text consistently. Sigh.)

My phone's screen resolution is at least as high as the tablet's though, so it should look equally nice on the phone, just smaller.

Is the default number of rows on the textarea too high (noting that it can be resized by the user unless the browser decides (like FF on Android) otherwise)?

Hi,

I see the pikchr.y file itself has a small copyright/license line, but you might want to consider a license file for all of it, if you're going to keep it as a separate project.

The raw markdown page is a dead link.

It looks like the height of the svg doesn't account for text around arrow/lines

arrow "on top of"; move
line "above" "below"; move
arrow "above" above; move
arrow "below" below; move
arrow "above" "on top of" "below"

however adding an invisible box makes it work:

arrow "on top of"; move
line "above" "below"; move
arrow "above" above; move
arrow "below" below; move
arrow "above" "on top of" "below"
box invis

Looks like a test, test 23

margin = 12pt;
arrow "on top of"; move
arrow "above" "below"; move
arrow "above" above; move
arrow "below" below; move
arrow "above" "on top of" "below"

Ok looking at test 23 it looks like I need to add an explicit margin:

margin = 12pt;

Would be nice to not have to do that but the margin setting works.

Richard, ..

Would it be worth adding support for Pikchr with the Fossil Wiki Markup with the same syntax as Markdown. Happy to have a go over the next few weeks as a background project noting:

1. Maybe Markdown is the new way :-), whence not worth spending any time on it.
2. Or maybe it already works, and I've failed the syntax test.

Comments?

Would it be worth adding support for Pikchr with the Fossil Wiki Markup with the same syntax as Markdown

He already added it via <verbatim type="pikchr"> :).

Thanks Stephan,

I'll do some more testing for my penance.

Re my penance, I've done up some diagrams for a project of mine which we will publish shortly. It might be of use since I've found the posts on here great for dealing with pic after a wee while. One (extremely) minor thing is that the scaling within the forum and the pikchr are interacting.Diagram 1 is scaled to 1.0, second to 0.6 and it seems to be a problem.

Hmmm. i've looked at this in pikchrshow and the results are what i would expect:

1. the scale=... setting is telling it to render at a scaled size and
2. the SVG is using "viewbox" sizing, which will shrink it as the viewbox gets smaller than the image's preferred size.

For the 0.6 scaling, my window needs to be smaller than about 1/3rd of my 1920-pixel-wide screen before it starts shrinking further. That's precisely what i would expect to happen, though. However...

The one problem i am seeing is that with scale<1, the text size is not shrinking as much as it does via a "pure viewbox" scaling, so it overlaps the containing shapes. My layman's analysis suggests that this is a problem with the scale setting, independent of the viewbox scaling: if the scale is at 0.6 and my browser is full screen (large enough where the image won't shrink) then the text overflow still happens. Richard can probably tell us why that happens, but it's the pre-pre-dawn hours in his timezone, so we'll probably have to speculate among ourselves until then ;).

Given that the SVG dynamically shrinks if needed, why do you feel you need scale=0.X to shrink that image down? Granted, that setting should definitely work properly if it's available, i'm just curious what your motivation is for using it.

ta,

agreed, its just the text size, not scaling. and agreed setting the scale is not needed often.

Hi,

I think this is great. I am getting the hang of the language and it's very fun. I toyed with diagramming sentences but the diagrams need work.

One comment is that I noticed this one liner doesn't display the text:

~~~ pikchr center
arrow right 200% "Markdown" "Source"
~~~

arrow right 200% "Markdown" "Source"

But of course it's easy to make it work with invisible boxes:

~~~ pikchr center
box invis
arrow right 200% "Markdown" "Source"
box invis
~~~

box invis
arrow right 200% "Markdown" "Source"
box invis

A sincere thank you,

Stephen

The text is actually present both times, when you look into the HTML+SVG. Selecting the image shows even small boxes where the text should be. Very small height.

Result 1:

<div style='display:block;margin:auto;width:152px;'>
<svg class="pikchr" width="152" height="12">
<polygon points="146,6 134,10 134,2" style="fill:rgb(0,0,0)"/>
<path d="M2,6L140,6" style="fill:none;stroke-width:2;stroke:rgb(0,0,0);" />
<text x="74" y="-5" text-anchor="middle" fill="rgb(0,0,0)" dominant-baseline="central">Markdown</text>
<text x="74" y="18" text-anchor="middle" fill="rgb(0,0,0)" dominant-baseline="central">Source</text>
</svg>
</div>

Result 2:

<div style='display:block;margin:auto;width:364px;'>
<svg class="pikchr" width="364" height="76">
<polygon points="254,38 242,42 242,33" style="fill:rgb(0,0,0)"/>
<path d="M110,38L248,38" style="fill:none;stroke-width:2;stroke:rgb(0,0,0);" />
<text x="182" y="25" text-anchor="middle" fill="rgb(0,0,0)" dominant-baseline="central">Markdown</text>
<text x="182" y="50" text-anchor="middle" fill="rgb(0,0,0)" dominant-baseline="central">Source</text>
</svg>
</div>

BBox of result 2 is much larger. I suspect that some of the size calculations are off without the boxes.

Ping @drh.

Idea where to look: Text attached to elements not taking part in the bbox calculation of the element (*), causing the image to be very low, placing the text elements outside the visible area.

(*) Maybe limited to lines ?

Even in result 2, with the invisible boxes, the "Source" line looks to be cut off a bit at the bottom.

There is no mystery about the problem. The code makes no attempt (yet) to compute a bounding box on text because:

1. Doing that is hard

2. Most text is contained inside of boxes and circles and ellipses and so doesn't really need a bounding box.

But there have been a lot of complaints, so I suppose I need to get busy and write the code. I'll try to have an update out soon.

The extra code will go near the top of the the pik_render() function, where it computes the bounding box for the whole diagram. Recent changes elsewhere in the code should make the text bounding box computation less difficult than it would have been when I first confronted the problem and decided to defer the solution.

i'm trying to wrap my head around pic by following:

http://ytdp.ee.wits.ac.za/help/gpic.pdf

and would like to report that the first diagram from that doc, once the troff macros are removed from the strings, comes out looking essentially identical to pikchr's interpretation:

ellipse "document";
arrow;
box "gpic(1)"
arrow;
box width 1.2 "gtbl(1) or geqn(1)" "(optional)" dashed;
arrow;
box "gtroff(1)";
arrow;
ellipse "PostScript"

Page 3:

box "box";
move;
line "line" "";
move;
arrow "arrow" "";
move;
circle "circle";
move;
ellipse "ellipse";
move;
arc; down; move; "arc"

Also page 3:

line "1";
line "1" "2";
line "1" "2" "3";
line "1" "2" "3" "4";
line "1" "2" "3" "4" "5";

If someone would care to curate a selection of predefined diagrams i'd be happy to integrate them into pixchrshow in the form of a drop-down list. Each just needs a descriptive name and the raw pikchr code (and possibly comments explaining to the user what's going on, in the interest of helping them learn pikchr). It probably wouldn't be all that difficult to add mini-markup to those so that pikchrshow could replace certain placeholders with info prompted from the user. That'd be "version 2," though.

Sorry, not sure how to write out what you would like...I'm trying to figure out my much simpler layout right now. I'll probably post it soon to get some opinions on it.

If someone would care to curate a selection of predefined diagrams i'd be happy to integrate them into pixchrshow in the form of a drop-down list.

Have you seen the tests? It might be nice to have some of those present in a drop down.

Have you seen the tests? It might be nice to have some of those present in a drop down.

i had not gotten that far, but just got the selection list working so will go through those and pik (haha!) a handful of them for inclusion.

Found two larger diagrams at Making Pictures With GNU PIC.

Note that I did not check all the other chapters for what examples they may contain.

Found two larger diagrams at Making Pictures With GNU PIC.

Alas, pikchr currently chokes on the 2nd token of the define lines.

Ach, I missed that they use macros. :(

Have you seen the tests? It might be nice to have some of those present in a drop down.

Sean, this is for you:

https://fossil-scm.org/fossil/info/d4bb5251b342eb5b

Summary:

• Drag/drop pikchr text files from your machine into the textarea. (My first-ever JS drag/drop.)
• The selection of "curated scripts" was added and contains all of the current test scripts from the pikchr repo. That increases the over-the-wire cost of the JS from 1.5kb to 8kb, but (A) it caches well, (B) that's probably the most useful collection of scripts we'll find, and (C) we can pare it down at any time later on.

Screenshot:

https://fossil.wanderinghorse.net/screenshots/pikchr-select-scripts-1.png

Edit: new and improved:

https://fossil.wanderinghorse.net/screenshots/pikchr-select-scripts-2.png

Sean, this is for you:

Very cool and thank you! I've gotta try it out, but it'll be several hours before I get to it tonight. This is a great addition to aide those in building pikchr diagrams.

I understand your current "curated scripts" to be a placeholder for other yet-to-be-written scripts which are actually curated. It seems to me that the curated scripts should be both interesting and instructive. Many users of Pikchr may prefer to learn by example, so we should provide them with good examples.

I'm still learning this language myself. But based on my one week of experience, I propose the following as a candidate "curated script":

AllObjects: [

# First row of objects
box "box"
box rad 10px "box (with" "rounded" "corners)" at 1in right of previous
circle "circle" at 1in right of previous
ellipse "ellipse" at 1in right of previous

# second row of objects
OVAL1: oval "oval" at 1in below first box
oval "(tall &" "thin)" "oval" width OVAL1.height height OVAL1.width\
    at 1in right of previous
cylinder "cylinder" at 1in right of previous
file "file" at 1in right of previous

# third row shows line-type objects
dot "dot" above at 1in below first oval
line right from 1.8cm right of previous "lines" above
arrow right from 1.8cm right of previous "arrows" above
spline from 1.8cm right of previous \
   go right .15 then .3 heading 30 then .5 heading 160 then .4 heading 20 \
   then right .15
"splines" at 3rd vertex of previous

# The third vertex of the spline is not actually on the drawn
# curve.  The third vertex is a control point.  To see its actual
# position, uncomment the following line:
#dot color red at 3rd vertex of previous spline

# Draw various lines below the first line
line dashed right from 0.3cm below start of previous line
line dotted right from 0.3cm below start of previous
line thin   right from 0.3cm below start of previous
line thick  right from 0.3cm below start of previous


# Draw arrows with different arrowhead configurations below
# the first arrow
arrow <-  right from 0.4cm below start of previous arrow
arrow <-> right from 0.4cm below start of previous

# Draw splines with different arrowhead configurations below
# the first spline
spline same from .4cm below start of first spline ->
spline same from .4cm below start of previous <-
spline same from .4cm below start of previous <->

] # end of AllObjects

# Label the whole diagram
text "Examples Of Pikchr Objects" big bold  at .8cm above north of AllObjects

I am, of course, happy to receive suggestions on how this script can be improved to make it more instructive to beginners.

I understand your current "curated scripts" to be a placeholder for other yet-to-be-written scripts which are actually curated. It seems to me that the curated scripts should be both interesting and instructive. Many users of Pikchr may prefer to learn by example, so we should provide them with good examples.

A few commits back i switched those from pikchr's tests/*.txt to examples/*.txt, under the assumption that those are intended for learning pikchr. The version currently running this site has only those 3 scripts preinstalled, one of which is the graphic you just demonstrated.

Looks like you or Stephan have added that in to the show page. I like this and probably should have originally directed Stephan there.

Perhaps some of those cold be in color, with both the hex color and natural language of "green", "blue", etc. Maybe others can think of what else to add in.

Just curious, why does the opening stanza thing need to be a capital letter? allObjects: [ won't work in the preview and neither will it if it begins with a number.

Just curious, why does the opening stanza thing need to be a capital letter?

"Variable names begin with a lower case letter; place names begin with upper case." [TR 116, p. 21]

Hey Stephan,

Drag/drop pikchr text files

When dragging a file into the text area, I see a light green dotted border, but the file icon that I'm dragging in has a red circle with a line through it. Dropping the file in doesn't display its contents.

Firefox console displays this:

dragenter  pikchrshow:1127:9
dragleave pikchrshow:1133:9

Does my file need to be a certain file type? I've tried .txt and .xml, both are legitimate pikchr code.

Do you think it's worth adding a link to pikchrShow to the hamburger menu? Which, coincidentally, is two years old today (at least in my US Pacific TZ): https://fossil-scm.org/fossil/thisdayinhistory?today=2020-09-11

It would also be nice to see thisdayinhistory in the hamburger menu as well.

When dragging a file into the text area, I see a light green dotted border, but the file icon that I'm dragging in has a red circle with a line through it. Dropping the file in doesn't display its contents.

The green is expected (for lack of a better (and easy to implement) indicator), but the "nope" icon might (i'm speculating) be a restriction of the environment - it might (speculating) not allow drop of external files. It "works for me" in FF and Chromium on Linux, but i can't say much more than that - JS drag/drop is completely new to me, as of a few hours ago.

Does my file need to be a certain file type? I've tried .txt and .xml, both are legitimate pikchr code.

It currently simply accepts anything which it can read (noting that the environment may restrict what it can read), but ideally it will be improved to accept only "text/plain" files, as soon as i can figure out how to do that properly. It should, during the drag, already have enough info to indicate whether the drop will be legal. It can be done, it's just a matter of learning how.

Do you think it's worth adding a link to pikchrShow to the hamburger menu?

i expect we'll have some links to it when we get around to having a help page for pikchr similar to the wiki/markdown format help pages. That hypothetical page would be linked to from relevant places, like those wiki/markdown format help pages. We haven't gotten that far yet, though.

The drag and drop is functioning for me with Firefox. If there's already text in the input window, the drop will erase it and fill in the contents of the file. You cannot drop more than one file in simultaneously, which I find perfectly acceptable, since two different files would likely have a very poor layout presentation.

Huh. It even works here on my Ubuntu desktop. This is the first time that I recall ever using drag-and-drop on Ubuntu.

How does one configure a drag source?

I am thinking about the Pikchr User Manual (which I am now working on). I have various example Pikchr scripts there, and it would be nice if the reader could simply drag one of those scripts over into a /pikchrview window in order to run it and experiment with it. Is that even remotely possible?

One extra complication: The user manual is written in Markdown.

How does one configure a drag source?

The DOM elements just need to listen to certain events. The gory details are at:

https://fossil-scm.org/fossil/file?ci=4d946271f73ed3f2&name=src%2Ffossil.page.pikchrshow.js&ln=174-232

noting that much of that is still voodoo to me. Still TODO is to restrict acceptance of drops to the text/plain mimetype. If you currently try to drop an image in it, it will try to import its contents as a script, which obviously isn't great.

JS supports 2 types of drag/drop:

• within the DOM (not (yet?) used here). Source DOM elements listen for drag events and then feed client-defined data (possibly extracted from those elements, possibly completely external) into the drag/drop engine, which target elements can then listen for.

• file drops from the OS/desktop environment into the browser.

They're slightly different, but not wildly so.

I am thinking about the Pikchr User Manual (which I am now working on). I have various example Pikchr scripts there, and it would be nice if the reader could simply drag one of those scripts over into a /pikchrview window in order to run it and experiment with it. Is that even remotely possible?

Kinda, yeah: if the pikchrshow renderer is in the same body then it can definitely work. e.g. keeping the renderer as a permanently-hovering-at-the-top element via JS. Whether it works between different DOMs (different pages/iframes), i'm not sure off hand, but it might. Even if drag/drop doesn't, we could add a popup of sorts, so that double-clicking on a script, or tapping a small "render" button near it pops up its rendered form. For hosting in the pikchr repo that would first require something like the "rabbit hole standalone CGI" mentioned earlier or require that the markdown pages get "built" and the renderings get injected at build-time via the CLI pikchr app.

One extra complication: The user manual is written in Markdown.

That is indeed a complication, because we'd need to tie drag-start resp. click listeners to the appropriate elements. That could hypothetically be done via an on-page-load callback (installed via the skin) which only runs on certain pages (by matching the URI against a regex) and looks for matching elements to extract script code from (e.g. .language-pikchr). That doesn't sound like an insurmountable problem, but i don't yet know if we can do DOM1-to-DOM2 drag/drop - need to research that.

You cannot drop more than one file in simultaneously, which I find perfectly acceptable, since two different files would likely have a very poor layout presentation

Indeed, if you try to drop more than one it "should" just take the "first" (noting that the OS environment will determine the order). i've tried mixing/appending arbitrary pixchr scripts together and the results are not great: each script starts drawing at the position the previous one left off, and settings such as scale will carry over from one to the next, which is not what anyone wants to happen.

Okay, I'm ready for help on this simple layout.

Ideally I'd like the top of the second row touching the bottom of the first row, with the row boxes 4-24 lined up with box 2.

What am I doing wrong?

boxrad=10px
box rad 7px "1" "Router"
box "3" "Wifi"
box "5" "Wifi"
box "7" "Wifi"
box "9" "Wifi"
box "11" "Wifi"
box "13" "Wifi"
box "15" "Wifi"
box "17" "Wifi"
box "19" "Wifi"
box "21" "Wifi"
box "23" "Wifi"
down
move to first box
box "2" "Wifi"
right
//move right
box "4" "Wifi"
box "6" "Wifi"
box "8" "Wifi"
box "10" "Wifi"
box "12" "Wifi"
box "14" "Wifi"
box "16" "Wifi"
box "18" "Wifi"
box "20" "Wifi"
box "22" "Wifi"
box "24" "Wifi"

edit...Andreas did it. Now the two rows are directly under one another.

Put a right before the move right.

Because of the down the exit point of the next box is the south point. That is where the move right then starts. By adding right you change direction and the exit becomes east as new starting point.

Better fix.

Remove the all the moves between the rows of boxes. No down, no move to, right from my first response.

Write

box "2" "Wifi" with .n at first box.s

I.e. place the north/top point of the new box at the south/bottom point of the first box. The new box is now under the first box, touching it. Now you can add more boxes as you will. As the direction never changed, these boxes are added to the right, creating your second row.

Brilliant! Thank you very much for the education.

boxrad=10px
box rad 7px "1" "Router"
box "3" "Wifi"
box "5" "Wifi"
box "7" "Wifi"
box "9" "Wifi"
box "11" "Wifi"
box "13" "Wifi"
box "15" "Wifi"
box "17" "Wifi"
box "19" "Wifi"
box "21" "Wifi"
box "23" "Wifi"
box "2" "Wifi" with .n at first box.s
box "4" "Wifi"
box "6" "Wifi"
box "8" "Wifi"
box "10" "Wifi"
box "12" "Wifi"
box "14" "Wifi"
box "16" "Wifi"
box "18" "Wifi"
box "20" "Wifi"
box "22" "Wifi"
box "24" "Wifi"

If you couldn't tell, I'm going to use this to document my switch. I'll keep this in my repo and also print it out.

I briefly tried something in MS Excel a few weeks back but it looked ugly.

Are you are aware of tangle ? This is a tool taking input written in a small DSL and producing graphviz dot files.

Oh, the repository I found uses fossil.

I am not sure if this is the same tool I found and played with a bit years ago. (My network is not very big).

No, not aware of that; thanks for providing the link. It looks pretty sophisticated and I'm happy to see it's hosted with Fossil!

@Richard,

Here's an interesting pikchr bug for you:

If the very last line in a script is entirely a syntax error, e.g. just x on a line by itself, the error report does not provide any context information. It outputs the top-most line of the script and just says "ERROR: syntax error", but does not mark the error spot with ^^^.

If that last line starts with a valid token or has a valid non-comment token after the invalid one, the error report is as expected, pointing to the problematic token.

e.g.

linerad = 5px
x # no context info

but:

linerad = 5px
x line # with context info

and

linerad = 5px
line x # with context info

Before we get too attached to it...

Is "pikchrshow" a suitable name? It was chosen on a whim as a tongue-in-cheek reference to the old-fashioned term for movies. Nothing more interesting immediately comes to mind, but suggestions are welcomed - at this point there's neither technical nor historical reason we have to be stuck with that name.

Still getting the hang of this...

B: box "B.c/C.c" ht 1 wid 1.5 fill LightGreen
  "B.e" at B.e +0.1,0
  "B.ne" at B.ne +0.1,0.1
  "B.se" at B.se +0.1,-0.1
  "B.s" at B.s +0,-0.1
  "B.n" at B.n +0,+0.1
  "B.sw" at B.sw -0.1,+0.1
  "B.w" at B.w -0.1,0
  "B.nw " at B.nw -0.1,-0.1

move to B.c -1,0

C: circle dotted ht 1 fill LightGray
  "C.e" at C.e +0.1,0
  "C.ne" at C.ne +0.15,0
  "C.se" at C.se +0.15,0
  "C.s" at C.s +0,+0.1
  "C.n" at C.n +0,-0.1
  "C.sw" at C.sw -0.15,0
  "C.w" at C.w -0.1,0
  "C.nw " at C.nw -0.15,0

# The center label got overwritten by the circle's color fill, so...
# move to B.c -0.5,0
#   "B.c/C.c"

dot color red at B.c

(With the pikchr addition, the need for ajaxifying the forum is becoming more acute.)

For those still following along:

pikchrshow now supports "stashing" a single pikchr into browser-local storage, the idea being to enable a user to switch back and forth between an image-in-progress and example images without fear of losing it.

C: circle fill yellow
down; L: line 0.4
left; arc cw from L.w
right; arc from L.e

Okay, so maybe it doesn't look like a person with their hands raised in jubilation to you, but that's what it is.

It's a sunflower!

FWIW, I think PikchrShow is perfectly acceptable, but I'm not opposed to someone coming up with a different name.

Achievement Unlocked: Find Your Source

Witness:

https://fossil.wanderinghorse.net/screenshots/pikchr-show-src-1.png

That red button in the top/right gets installed by the JS call seen in the console window, but its color/style is a placeholder. It will be restyled with an icon representing "toggle between this SVG and its pikchr source code" as soon as such an icon magically makes itself available.

Tapping on that ugly red placeholder toggles between the rendered pikchr and its source code:

https://fossil.wanderinghorse.net/screenshots/pikchr-show-src-2.png

Notes of interest:

• This requires the new branch in the pikchr tree which stuffs the original pikchr script into the svg's metadata so that arbitrary downstream clients (in this case our JS) have access to the source.
• It requires some small amount of JS code which isn't quite yet checked in.
• The source code textarea view is sized to precisely the same as the svg image, so there's no undo UI shifting going on.

C: circle fill yellow
down; L: line 0.4
left; arc cw from L.w
right; arc from L.e

https://fossil.wanderinghorse.net/screenshots/pikchr-show-src-1.png

https://fossil.wanderinghorse.net/screenshots/pikchr-show-src-2.png

Those aren't quite so ugly now, but they still need to be improved:

• https://fossil.wanderinghorse.net/screenshots/pikchr-show-src-3.png
• https://fossil.wanderinghorse.net/screenshots/pikchr-show-src-4.png

The clipboard-copy button copies the source for the currently-selected view (SVG or pikchr).

(Edit: the buttons have since been moved to the left so that they don't move around when pikchshow switches images or the use resizes their viewbox.)

Those aren't quite so ugly now, but they still need to be improved:

Accomplished:

• https://fossil.wanderinghorse.net/screenshots/pikchr-show-src-5.png
• https://fossil.wanderinghorse.net/screenshots/pikchr-show-src-6.png

Tapping the yellow button toggles between SVG and source code views. There's an annoying, but only cosmetic, layout bug when doing so for centered pikchrs, but it works rather well aside from that.

Those buttons on the left appear and disappear dynamically as the mouse moves over the pikchr. Tapping on the pikchr also toggles them. That said: it won't work for you yet because it requires a patch to pikchr.c (which is due to be merged "real soon now").

Where exactly do these or the previous ones show up? I don't see the old ones on the default skin or the ardoise skin.

https://fossil-scm.org/skins/ardoise/pikchrshow https://fossil-scm.org/fossil/pikchrshow

Where exactly do these or the previous ones show up?

Currently only on my machine ;). This feature requires that the pikchr-generated SVGs contain (stored in their metadata) the original pikchr script code. My patched copy of pikchr adds that code to the SVG's metadata so that we can have this view-swapping feature (the main reason for it is to simplify learning of pikchr by being able to see the pikchr code for any diagram by simply tapping the button).

That patch is due to be merged very soon - i'm just waiting on a confirmation from Richard before merging something into his otherwise pristine pikchr trunk, but it's the middle of the night in his timezone (at not quite 8am in mine).

As soon as that patch is checked in and that version of pikchr.c is added to fossil, this feature will automatically activate. It's already in place and working but currently can't do anything because the generated SVGs don't contain their original pikchr source code. (If you open your dev tools in pikchrshow or /forumpost, you may see warnings about the missing pikchr source code.)