Pangraph is an idea for a vector graphics language suited to hand-coding and for embedding in a panscript web page. It follows much the same inspiration as panscript and is intended to be a dialect of it, just as SVG is a dialect of XML. The panscript environment is intended to be more unified and more human-readable than the XML/HTML world, in fact it is comparable to Wikitext and a pangraph image can be coded into a wiki page alongside the written text.
I'm sketching out the basics without reference to the present panscript syntax. The idea is to then compare the two syntaxes and pick the best features of both for a unified language.
SVG is the current standard web language for human-readable graphic files, but it has some serious issues with human readability. Firstly, it inherits the code salad issue which is one of the reasons that HTML5 sucks: semantic, positional and styling information use wildly differing semantics, essentially making it three incompatible languages rolled together, and the structural semantics are verbose to the point of obscuriity. Panscript is my overarching proposal to fix the web and, ultimately, the digital user workspace.
A key element of panscript is the idea of code re-use, exemplified by the transclusion of code in the MediaWiki content server.
Pangraph therefore has three inspirations, as:
A pangraph image may be parsed to svg by a web server, for example using an XSLT style sheet. What panscript does for the web as a whole, pangraph does for vector graphics.
Code essentially comprises two things: objects and metadata. Another fundamental concept is that of size.
Metadata includes all the stuff typically found in html <head> and <!-- --> (comment) containers, i.e. anything that is not directly related to the displayed content.
Everything else, whether rendered or not, is a graphic object. There are a handful of primary object classes, such as lines and fills. Everything else is a property of a primary object, including embedded (e.g. grouped) objects, and embedded or linked executables (methods).
Many things such as guides, connectors, layers and so on are just primary objects with special properties such as stickiness, transparency and so on.
pangraph does not insist on absolute sizes of anything. You can scale everything relative to the frame it finds itself in. All such positioning measurements are made in "pangraph units". The larger of the horizontal and vertical drawing dimensions is deemed to be 1,000 pangraph units, the shorter is reduced in proportion. For finer resolutions, decimals are used.
However, you can use fixed units if you need to, for example to ensure uniform font and line weight when several images are displayed at different scalings, or to fix the drawing size when flowing text around it.
There are only a few primary object classes, perhaps surprisingly few:
Typical properties include:
Many common object classes are primary types with specific properties defined, such as:
Other common classes comprise a primary type with a specific second type embedded:
Like wikitext, pangraph uses easily-found characters, simple repetition and short strings. Candidate characters for the most common uses are:
, . ; ' # / [ ]
Maybe I ought to use one of these for the metadata container.
Metadata includes anything that is not directly related to the displayed content such as declarations, comments and so on. In pangraph it can take two related formats:
A single line is denoted by an initial ! character, and terminated by an end-of-line, <cr><lf>, or similar:
! This is a single line of metadata or comment.
Multiple lines are delineated by a
!! ... !! container:
!! This is a multiple-line set of metadata or comments or whatever. It can contain: [t /c pangraph code snippets, that will not be executed, /c ]t <p>Bits'n'bobs in other languages, that will not be executed,</p> white space and anything else !!
Objects are delimited by a
[x ... ]x container, where x is the object class:
[t This is a simple text object ]t
The container markup provides the same functionality as an XML container such as
<text> ... </text> but is quicker to type and less cluttered to read.
Updated 11 June 2016