[rfc-i] graphics support

Phillip Hallam-Baker hallam at gmail.com
Sat Apr 21 07:27:47 PDT 2012

It seems that we have two standards here

1) For the existing format, any problems MUST be ignored

2) For a proposed replacement, absolute perfection.

I just want something that is better than the current one. That does
not mean that every pixel must occur in the exact same place on every

The documents we produce are really not anywhere good enough for that
difference to make the slightest difference in any real world
situation. The current documents are so terrible that many people will
buy the nutshell book to implement the spec from because it is easier
to read.

What should be the standard here is the likelihood of someone
misinterpreting the document due to the formatting constraints. For
the plaintext series I think that is unnecessarily high. The ASCII art
looks like scribbles by a lunatic at the best of times.

We can reduce the read error rate very easily here. SVG is clearly a
major step forward. Requiring the new read error rate to be zero is
just a way to discourage participation - which I think is an objective
for many IETF-ers.

On Fri, Apr 20, 2012 at 11:27 PM, Paul E. Jones <paulej at packetizer.com> wrote:
>> >One thing I do not fully understand is how text is handled in SVG.
>> Text is just standard Unicode text, usually in UTF-8.  Same as HTML.
> That's what concerns me a little...
>> >Fonts change with time to and changing one font for another where a
>> >character needs precise placement might mean the character is not
>> >rendered in the right place.  Is that an issue with SVG?
>> You don't necessary place each individual glyph (although you can), just
>> the beginning of a given text run.
> And different fonts can render text differently, perhaps resulting in
> rendering the text in the wrong position.
>> Again, this is no different from HTML (especially with CSS placement
>> attributes).
> You're right, but one reason this works is that actively maintained web
> sites are always using the latest fonts, etc.  I suspect there are issues
> going from one platform to another.
> A reason for embedding fonts in PDF documents, I assume, is to ensure proper
> reproduction when that font is not available on the machine displaying the
> PDF.
> Anyway, I'm definitely not an SVG guru and not sure what issues might exist
> if we were to use them and then fonts referenced are no longer available 10
> years later.  Perhaps it will still work because whatever substitute font is
> used would be in a similar family and rendered with precision?  I guess it
> might "look" different than the original, but equally effective.
> Paul
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

Website: http://hallambaker.com/

More information about the rfc-interest mailing list