Hi,

Thanks Stephan for creating the pikchrshow page.

It'll be much nicer to use, rather than hitting preview on the forum.

I noticed it doesn't support center, or maybe I'm using it in the wrong spot.

example:

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

Error output:

center
^^^^^^
ERROR: syntax error

I'm fine if everything aligns to the left, but if I made a mistake, please let me know.

IIRC center is an element attribute, and you have to apply it to the elements with the text you wish to center.

I thought so too, but see drh's post here, and see the whole thing is centered.

I see that drh put the center on the fenced code block wrapping the PIKcher code. Not in the PIKcher itself.

So box aligns to the left. center box throws an error.

To repeat:

drh put the center on the fenced code block wrapping the PIC code.

See:

~~~~ pikchr center
... PIC code ...
~~~~

I don't think that the pikchrshow page supports that. Yet. Because you can only enter the PIC code there, and this setting is outside that. I suspect that it requires a checkbox on the page to set this type of information. Or an extension of the PIKcher grammar to allow the specification of such global settings.

I don't think that the pikchrshow page supports that.

Thanks for the confirmation. I didn't know if I was doing something wrong, or if it's not implemented.

There is also of course the question if it should.

I mean, using center in this manner is for centering of the image in its using context, i.e. wiki page or doc file. In the pikchrshow page there is no real context to center it into.

That is true.

I'm simply a) providing feedback/input on this new page and b) wondering if I did something wrong for center not to function.

There is also of course the question if it should.

The alignment was admittedly simply overlooked. That could be done one of several ways, probably completely client-side, but, as you say, "should it?" For a preview, the alignment would seem to make little, if any difference.

Let's move that to "version 2" for the time being.

For a preview, the alignment would seem to make little, if any difference.

The only difference would be to help center things if someone were to copy/paste from your tool into the forum or into documents.

Let's move that to "version 2" for the time being.

That is perfectly acceptable. I hope others will use this thread to report things they find.

The only difference would be to help center things if someone were to copy/paste from your tool into the forum or into documents.

Darn you and your logical arguments! That implies the existence of separate preview mode which can output the pikchr script in either markdown or fossil wiki format. It would simply take the text from the textarea and wrap it with the appropriate tags, using a select list or radio button group to select alignment.

Okay, let's move that to version 1.01 for the time being. It's easy to do, it just needs to be done. Maybe another button which toggles the preview part between SVG and copyable markdown/wiki content (a re-use of the clipboard button widget). Not tonight, though. It would also be interesting to be able to copy the SVG element for dropping into Inkscape for further editing. Okay, so 3 preview modes: rendered, markdown/wiki, and raw SVG. But not tonight. Probably not tonight.

Thanks for considering my input.

Probably not tonight.

Good. Enjoy your morning!

Okay, so 3 preview modes: rendered, markdown/wiki, and raw SVG. But not tonight. Probably not tonight.

Forgive me, for i have, once again, blatantly lied. Kinda, anyway - it's not "tonight" any more, but is "very early morning" in my timezone.

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

Summary of improvements:

• 4 different preview modes: rendered SVG, markdown, fossil wiki, and raw SVG.
• Each preview mode has a clipboard copy button to copy its content. (Rendered and raw SVG copy the same thing - the underlying SVG, which can be pasted into an HTML doc or saved to a file and opened in Inkscape.)
• An alignment selection option for the two markup modes: left (=default) or center. Right alignment doesn't appear to be a real thing in pikchr.
• If the server reports an error in the preview, the preview mode toggle is disabled until the error is resolved.
• Still having trouble writing pikchr (but like the name - google will find it easily at some point).

There's some unfortunate "twitching" of the various DOM elements when switching preview modes, and it may switch back and forth between 1 row (side-by-side) and 2 rows (top-to-bottom arrangement) when switching modes, depending largely on the browser width and rendered SVG width. It's usable but can sometimes be a bit visually jarring. Ideas for how to improve that (ideally without pinning each of the two major elements at half of the page width) are welcomed.

Copying and saving the raw SVG output of the objects as objects.svg causes an error when attempting to open in InkScape.

XML Parsing Error: undefined entity

That might (not certain) be a side-effect of pikchr structural changes made since Raw SVG preview was implemented (it now includes a wrapping DIV element). Or it might be a side effect of a change made a few hours back when eliminates the assignment to innerHTML.

i'll need to take a look, but should have it fixed for you soon.

Copying and saving the raw SVG output of the objects as objects.svg causes an error when attempting to open in InkScape.

XML Parsing Error: undefined entity

i think the latest trunk should resolve that for you. The raw SVG output now opens in two different SVG viewers on my machine, including Inkscape.

If that doesn't resolve it for you, please post the pikchr which is breaking it for you.

Yes, it's mostly fixed.

This displays as one word in Inkscape

text "Examples Of Pikchr Objects" big bold  at .8cm above north of AllObjects

XML generated in pikchrShow:

<text x="281" y="14" text-anchor="middle" font-weight="bold" fill="rgb(0,0,0)" font-size="125%" dominant-baseline="central">Examples&nbsp;Of&nbsp;Pikchr&nbsp;Objects</text>

<text x="281" y="14" text-anchor="middle" font-weight="bold" fill="rgb(0,0,0)" font-size="125%" dominant-baseline="central">Examples&nbsp;Of&nbsp;Pikchr&nbsp;Objects</text>

That's how the SVG is coming from the server, but it's not valid SVG, at least not as written. Perhaps (not sure)   can be made legal via additional SVG namespace declarations or some such, but two SVG viewers on my system choke on those elements.

This will need to be resolved in pikchr, either by eliminating the nbsp's or figuring out how to make them legal via additional declarations (assuming that's possible - i'm not an SVG guru).

@Richard here's a StackOverflow post which seems to offer a solution which doesn't require nbsp:

https://stackoverflow.com/a/8100970

Note the addition of a TSPAN tag.

Pikchr is now updated to output a raw U+0080U+00a0 rather than  

Pikchr is now updated to output a raw U+0080 rather than  

Based on having had to deal with a very similar problem when generating such gaps from JS code (which escaped me last night, else i'd have proposed it then), it seems to me that 00A0 is the better semantic match. 0080 is a "padding" character, whereas 00A0 is a non-breaking space. Presumably pikchr should be using the nbsp? (That said, perhaps 0080 behaves equivalently in practice - no idea, really.)

Source: https://en.wikipedia.org/wiki/Latin-1_Supplement_(Unicode_block)

Copying and pasting the (non-raw) SVG output and saving into a file like objects.svg and attempting to open in inkscape causes this message: Failed to load the requested file c:\sean\documents\objects.svg

I tried this same thing with the objects example and cardinal direction example.

So I don't know if this is a inkscape issue or an issue with the generated output with pikchr show.

Also, the spacing issue doesn't look resolved. Examples Of Pikchr Objects runs together as one word.

I tried this same thing with the objects example and cardinal direction example.

Did none of them load? The only inkscape tests i've done so far were on custom piks, but i'll try with the sample scripts later on. i have a few SVG viewers and sometimes one will choke on something which the other does not.

Also, the spacing issue doesn't look resolved. Examples Of Pikchr Objects runs together as one word.

i'm fairly certain that change uses the wrong special spacing character, and that it should be 00a0 instead of 0080. 00a0 is what i use in JS when i need an NBSP but can't use an HTML entity.

Did none of them load?

Nevermind - it's been corrected. That particular set of clipboard contents was including the containing DIV element, which make it invalid SVG.

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

Fix confirmed! Thank you.

Hi Stephan,

Is it possible to make ctrl + enter execute the contents in the input area of pikchrshow? If so, is that something you would consider adding in?

Just a little bit more time saving from

box "keyboard"; arrow <->; box "mouse";

Is it possible to make ctrl + enter execute the contents in the input area of pikchrshow?

That's a really nice idea. i don't know off hand how to do it, but i've seen it done in other JS apps, so know it can be done.

My workstation is a bit overwhelmed right now compressing OS images, making everything else really slow, but once it recovers i will add that.

Bind a keypress event and check the ctrlKey flag.

Ctrl+Enter is a de facto standard. Jupyter, R Studio, IntelliJ IDEA, browser Developer tools... Lots of things obey it.

Ctrl+Enter is a de facto standard. Jupyter, R Studio, IntelliJ IDEA, browser Developer tools... Lots of things obey it.

i will be adding it to wikiedit and fileedit as well, to automatically switch to/update the preview.

The "U+0080" is an error in the comment. The code turns out to be correct. It's been writing "\302\240" all along, which is UTF-8 0xc2 0xa0 which translates into U+00a0

Thanks for updating the comment, however, it looks like words are still RanTogetherAndDon'tHaveSpaces when saving the output as SVG.

This is what I would expect:

circle "Hello World" fit

Exporting as svg shows this:

circle "HelloWorld" fit

Unable to repro. When I load the raw SVG, it shows the space as it should.

Interesting.

circle "Hello World" fit

Generates this raw svg on https://fossil-scm.org/fossil/pikchrshow:

<svg xmlns="http://www.w3.org/2000/svg" class="pikchr" viewBox="0 0 121.418 121.418">
<circle cx="60" cy="60" r="58.5492" style="fill:none;stroke-width:2.16;stroke:rgb(0,0,0);"></circle>
<text x="60" y="60" text-anchor="middle" fill="rgb(0,0,0)" dominant-baseline="central">Hello&nbsp;World</text>
</svg>

Are you doing something different?

This line in fossil.page.pikchrshow.js is HTML-izing the valid SVG XML put out by pikchr.c:

 this.e.taPreviewText.value = svg.outerHTML;

Another related case appears to be

 P.response.raw = P.e.previewTarget.innerHTML;

This is a problem because it appears the "copy SVG to clipboard" code is reaching into the HTML DOM to get the text instead of just sending P.response.raw to the clipboard.

HTML-flavor SVG allows  . True XML does not.

Also, code that still needs to do "innerHTML" type things should probably be calling innerText or textContent instead to get raw text, rather than the HTML-ized version of data that did not start out HTML-ized.

There is no standard "outerText", but a bit of DOM manipulation should allow you to get the same effect with a few more steps using one of the two linked functions. Basically, jump up a level in the DOM first.

This is a problem because it appears the "copy SVG to clipboard" code is reaching into the HTML DOM to get the text instead of just sending P.response.raw to the clipboard.

That's intended: the raw response contains information other than just the SVG, e.g. its source code in an adjacent node, and the copy is intended to only copy the SVG part.

Also, code that still needs to do "innerHTML" type things should probably be calling innerText or textContent instead to get raw text, rather than the HTML-ized version of data that did not start out HTML-ized.

Those work very differently. Try opening a dev console and typing:

document.body.innerText

and compare that with:

document.body.innerHTML

All assignments/writing to innerHTML were recently factored out because it's ostensibly a security risk, but we still need to read innerHTML quite often.

You can quibble with my diagnosis if you like, but I don't see how you get around the fact that you got the data correctly from the Ajax POST /pikchrshow call, but it's wrong in the "copy SVG to clipboard" click handler.

The raw SVG text needs to be preserved somewhere, somehow.

The raw SVG text needs to be preserved somewhere, somehow

The raw SVG is parsed out of the raw response text (a multi-element HTML bundle) on demand via the DOM's parsing API. The only text we retain in memory across all preview modes is the raw response. If that's not happening then you've discovered a bug, but you'll have to show me how it's manifesting, as the preview and clipboard features are both working exactly as intended (just tested a minute ago).

HTML-flavor SVG allows  . True XML does not.

i can reproduce that, and it's apparently caused by the browser reinterpreting raw u00a0 as nbsp (when it should leave those well enough alone). There's a workaround for that i can implement next time i'm on the computer. Other than that unfortunate mis-conversion, i'm not aware of any mangling of the SVG going on.

How do you suspect drh had different results than I did with "hello world" vs. "helloworld"?

raw SVG is parsed out of the raw response text (a multi-element HTML bundle)

A JSON return would probably be better. SVG should go into HTML mode in trapdoor fashion only, like C code into a compiler. Just as you should generally not attempt to reconstruct the C from the .o file, you shouldn't try to extract SVG from any HTML DOM element.

This is why I was talking about P.response.raw: it is the raw API return value that hasn't gone through an HTMLization step. Maybe you want to premasticate it some, but there should be no cross-pollution between raw SVG and HTML. HTML output is a lossy transform, as we're now seeing.

you'll have to show me how it's manifesting

I thought the steps were clear already:

1. Open developer tools to Scripts/Source tab; reload.
2. Type Sean's test case in the input box.
3. Set a breakpoint on the Ajax onload event for the API return.
4. Press "Preview." The returned SVG doesn't have " " in it.
5. Set another breakpoint on the "copy to clipboard" function.
6. Click the copy button.
7. Notice that the copied text includes " ".

It may be helpful to narrow the window between those two event handlers, but I should think the window's narrow enough already to make the bug's source obvious to one familiar with the code. I came up with that much just poking around.

How do you suspect drh had different results than I did with "hello world" vs. "helloworld"?

Once he changed those to u00a0, and i wasn't seeing npsp in the CLI output i didn't think about it anymore. In hindsight, that was dumb, as the browser's obviously doing something different than the CLI. Why on earth the browser translates u00a0 to nbsp is a mystery, though, as the latter is a data-entry-friendly form of the former. Sigh.

That's fixed now in the trunk. As Warren suggests, we have to extract and store the raw SVG from the server, before the DOM gets ahold of it, and use that string for clipboard-copy purposes.

A JSON return would probably be better.

That is very probably true, and i may well do that "real soon now." (i've been avoiding anything more than the most trivial computing the past couple of days because my left hand is giving me grief.)

This is why I was talking about P.response.raw: it is the raw API return value that hasn't gone through an HTMLization step.

And i missed that the browser was converting u00a0 to its higher-level nbsp form.

HTML output is a lossy transform, as we're now seeing.

Not anymore :). The trunk fixes this to store the SVG part of the raw response text separately, before the DOM API gets its mitts on it.

I thought the steps were clear already:

They were - i missed, until later, that your comment about nbsp was a consequence of the rest of what you'd said. It initially came across to me as a separate point.

In any case, thank you for catching that.

Thank you Warren for pressing on this more. I didn't exactly know what more to do to check into this and give input. Thanks for the links and the information for Stephan to research this.

Thank you Stephan for working with Warren on this and making the fixes, even in times of your hurt hands. Your dedication to the project is invaluable. With this fix, svg files can be opened in a browser and words are properly spaced.