[rfc-i] graphics support

Leonard Rosenthol lrosenth at adobe.com
Sat Apr 21 11:31:22 PDT 2012


On 4/21/12 5:27 AM, "Paul E. Jones" <paulej at packetizer.com> wrote:
>And different fonts can render text differently, perhaps resulting in
>rendering the text in the wrong position.

Yes, but that's true today when rendering the current ASCII files - since
a user can choose ANY FONT to view them.  I would expect that the font
chosen would not be one that would really matter (say Times, Arial, etc.)


> 
>> 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.

Actually, sites today are either choosing to use the "default fonts",
choose common fonts, or rely on "web fonts".  In the last case, the font
data is dynamically streamed from some server (Google, TypeKit, etc.) to
enable richer typography.  This is part of CSS2, the Fonts module.

But how important is this to the type of things being described here -
especially if ASCII and ASCII art are OK today?!?


>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.

Right.  That's one advantage of EPUB over "unpackaged" HTML - that you can
embed (obfuscated) web fonts into the package to achieve a similar result
to 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.

Really depends what you are trying to achieve with the text in the
graphicŠ.

Leonard



More information about the rfc-interest mailing list