W3C home > Mailing lists > Public > www-svg@w3.org > November 2002

RE: General Text Metrics Requirement

From: Allen Razdow <arazdow@mathsoft.com>
Date: Thu, 21 Nov 2002 09:59:02 -0500
Message-ID: <8D1EA20CE6AB1043956A27D60E468F1C0115B8AB@distrib.mathsoft.com>
To: "'Thomas E Deweese'" <thomas.deweese@kodak.com>
Cc: "'Tobias Reif'" <tobiasreif@pinkjuice.com>, "'www-svg@w3.org'" <www-svg@w3.org>, "'Kanaskie, Kurt A (Kurt)'" <kkanaskie@lucent.com>

Thomas,

Thanks much for considering this problem.  

Bottom line, I believe that adding something like this to SVG for text only
would be sufficient and important, and avoid the need to go to scripting
for a large number of common applications. This would in turn make SVG more
complete and portable.  One can argue that it's not a "wart" because text is
so basic, and is anomalous in having implicit dimensions hard to know in
advance. You don't need script to align rectangles, you shouldn't need it
to align text.

In any case, I sincerely hope the committee considers this issue, it's
pivotal
for our applications having over a million users, and I'm sure we're not
alone!

-allen

PS
I did wonder about order of evaluation and whether extra "passes" would be
required for some uses of the functions I proposed.  You're right about
referering to
entities, in my first message I proposed that these
attribute-functions refer to an entity ID, but i wasn't sure whether the
namespaces
at the entity level would be accessible to an interpreter of attribute
values.
If so, it actually simplifies the syntax, because you just refer to
the ID of the text or other entity rather than use a literal string.



-----Original Message-----
From: Thomas E Deweese [mailto:thomas.deweese@kodak.com]
Sent: Thursday, November 21, 2002 8:17 AM
To: Allen Razdow
Cc: 'Tobias Reif'; 'www-svg@w3.org'; 'Kanaskie, Kurt A (Kurt)'
Subject: RE: General Text Metrics Requirement


>>>>> "AR" == Allen Razdow <arazdow@mathsoft.com> writes:

AR> In general, many applications (like math typesetting, building
AR> data graphs and charts, etc) require "runtime" metrics of things
AR> as the graphics are constructed.  Does SVG aim to allow this?  The
AR> workarounds thus far suggested may work, but seem indirect for
AR> such a basic requirement.

    I think the SVG DOM provides what you are asking for, but you have
to use scripting.  

AR> A general (extensible) set of functions to return measured values
AR> of things like strings and substrings would make this easier.

    There is it is just part of DOM.

AR> (using variable-spaced fonts).  One suggestion was to add such
AR> functions to the "transform" syntax, since that's where they'd
AR> often be needed. For example, the strings above would be
AR> "translated" an amount based on the width of the substring upt to
AR> the first dot.  transform="translate(SubstWidth('.','x.y'),0)"

    SVG already takes a lot of heat for having overly complex
attribute values.  This would make a number of attributes (at least
for dynamic profiles) full programming languages.  You also have issues
like when would that function be evaluated?

    Also your example looks really attractive until you realize that
you need to know all the font rendering details (font-family, size,
text-length, etc) to calculate this correctly, you really need to
refer to the text element you want to measure - which would start to
make your nice concise example not so nice and concise I think.

    There has been talk about adding 'parametric' type layout to SVG
and some of them do involve adding 'functions' to attributes so what
you are suggesting is not out of the question, but I think it is more
complex than it appears at first.

AR> Do you agree that this should be addressed somehow in SVG?  When I
AR> first asked our developers to look at using SVG in Mathcad they
AR> came back and said "it's too hard to measure things".

    Well it is 'addressed somehow in SVG' right now, but I agree that
it needs to be addressed better.

BTW let me add my two cents on how to do your example:

<text ...><tspan x="100"            text-anchor="end"  >foo.</tspan
         ><tspan x="100"            text-anchor="start">bar</tspan
         ><tspan x="100" dy="1.2em" text-anchor="end"  >foobar.</tspan
         ><tspan x="100"            text-anchor="start">blatz</tpsan
         ><tspan x="100" dy="1.2em" text-anchor="end"  >x.</tpsan
         ><tspan x="100"            text-anchor="start">y</tpsan></text>

I know not the easiest solution, and not very general but it does work...
Received on Thursday, 21 November 2002 09:59:07 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:23 GMT