Re: SSD TBW

On 8/23/2026 9:59 PM, Lawrence D’Oliveiro wrote:
> On Sun, 23 Aug 2026 11:44:45 -0700, Don Y wrote:
> 
>> Text is a piss poor match for graphic entities and other
>> abstractions.
> 
> Maybe it isn’t. I already pointed out how you should be using
> resolution-independent SVG for your master graphics.

And I already pointed out that vector/line art doesn't work when
rasterized at very low resolutions.  You have to hand-draw glyphs
and other symbols at those sizes -- especially when your choices
for each pel are ON and OFF.

Put a serif on a glyph and the serif looks disproportionately large.
Dot an I and the dot is 1/3 the size of the i!

We used to spend considerable amount of time hand-drawing fonts for
dot-matrix printers (teleprinters, etc.)  You end up with glyphs
that deviate significantly from the "ideal" simply because you don't
have room to express any detail.

Consider an uppercase A.  The apex will likely be in the 3rd (of 5 across)
pel in the first row.  The feet will anchor in the 1st and 5th pels of
the bottom (of 7 high) row.  Now, you have to get from each foot to
the apex -- knowing that there is only *one* column between your start
and end points.  Your vector art would cross that column in 5 different
places along its way; you get to pick *one*.

By hand, you would likely draw vertical uprights from each foot (deviating
from what your vector art suggests) and bridge the column to the apex
very close to that point -- so a single dot IMPLIES the sloping legs.

Imagine how you would draw an @.  Or, &.  Get out some quadrille paper
and a soft pencil/crayon.  It's fun!  (perhaps your printer shouldn't be
able to print these glyphs?  Prohibit people from using them in
correspondence?)

> Take apart a document from common present-day office suites and what
> do you find at the core? XML!

Really?  Have a look at the files created by these mainstream tools:
    <https://mega.nz/folder/oiJlVAAQ#RD9jjzpEQz0Muskjn2L3jA>

Now, suppose I had a tool that told you that the 47th byte (of any file)
was changed to a 0x22.  What use is that information to you, beyond "this
file doesn't agree with this OTHER file!"

If, for example, I changed the default typefaces loaded in the FrameMaker
file, that would show up as a difference (the typefaces names are in ASCII).
But, not one that made a REAL difference in the rendered document -- if I
never referenced the typefaces elided!  How would you know that, looking at
the diffs?

Even for tools that have the ability to generate XML, there is usually so much
cruft that you can't tell what the effective difference is, examining the text.

Remember, the goal is to UNDERSTAND the differences, not just note that
they exist -- as they may be inconsequential.

[E.g., a common RCS practice was to include commit messages IN the
affected documents.  This clutters up the document.  Many folks opted
to remove them from HEAD, going forward.  But, there seem to be a
lot of differences between the version prior to their removal and
after -- despite the fact that all are effectively commentary.]

Would you look for a bug or anomalous behavior in a source file that
had lots of differences -- but, none that actually cause different
CODE to be generated?

#define TWO (2)
...
X = TWO

vs.

X = 2

Two different lines yet no difference in the resulting binary.