ivoatex architecture diagram: fix box width

[Markus Demleitner]

Dear Std+Proc,

I hope you don't mind discussions on ivoatex issues here, even if
they are sometimes a bit technical.  Many of these are actually
closely linked to Standards and Processes, and of the existing IVOA
lists, this seems the most appropriate.

This message is about the architecture diagram, which, with the
increasing number of standards, is becoming rather crowded.  A simple
countermeasure would be to abandon the fixed width of the boxes --
this will give the diagram a somewhat less regular appearance, but it
will loosen things up a lot.  See

https://docs.g-vo.org/ad-scaledbox.svg

if you have a javascript-enabled SVG viewer, which your browser most
likely is, or https://docs.g-vo.org/ad-scaledbox.png otherwise).

So, the first question I'd like to ask is: do we even want this?

Assuming we do, there's a nasty technicality: I don't know how to do
this in SVG, and racking my brain as well as a web search engine for
a while has not changed this.  It seems largely impossible to stroke
and fill the (padded) bounding box of a text using just SVG
primitives.

If anyone knows of a way to do that: I'd be very grateful for
enlightenment.

Assuming that won't work, there are a few alternatives for getting
variable-width boxes.  One is what I'm currently implementing in the
archdiag-fix-boxes branch on github ivoatex,
https://github.com/ivoa-std/ivoatex/tree/archdiag-fix-boxes ,
which is to fix the box widths through javascript; that's what is
producing the images above.

While I'm pretty much against executable content in image formats in
general, this will probably work in most users' browsers.  Inkscape,
however, thankfully does not execute javascript in SVGs.  While
that's of course good thing, in this particular case it means the PDF
rendering -- which is what's used in the PDF renderings of the
standards -- will have constant-width boxes.  So... it won't really
work this way, I guess.

Another alternative would be to try and compute the width in the XSLT
that makes the SVG from the XML input.  That's probably not as crazy
as it sounds: We force a font, and its metrics should be easily
figured out.  Sure, kerning might spoil this a bit, but that's
probably not even visible.

Someone would need to figure the details out, though, and I'm not
sure I'm wild about this sort of math in XSLT.

Something pretty straightforward would be to put the width into the
standards element in archdiag-full.xml.  The positions are manually
written anyway, so instead of

	<rec name="RegTAP" x="55" y="180"/>

you'd then write

	<rec name="RegTAP" x="55" y="180" width="60"/>

I like this pretty much -- simple and not too ugly.

I've still not gone ahead for one simple reason: it might break
existing documents.  Now that I write this, I notice that putting in
90 for a fallback would ensure backward compatibility -- and would be
rather straightforward in XSLT.

So... what do people think of mixed-width boxes in principle?  And
if we want them, how would be do them?

         -- Markus