RE: proposal for text layout with positioned glyphs, anchoring and bidirectionality

Hi Cameron,

I'll try to respond in-line, adding >'s as it seems appropriate.

David Dailey:
>> I'm not quite sure if what we're talking about here is for an enhanced
>> 1.1 or for 2.0?

>Either, really, depending on whether it makes sense to have a Third
>Edition of SVG 1.1 or not.  The proposal is a reworking of regular text
>layout in SVG to make it a little more sensible and implementable.  It
>doesn’t add any new features.

Well, sigh, clearly much of what I'm talking about here would fall in the category of new features, but appropriate, I think to Doug's call for community input on SVG2.0. 

>
>> 1. clarification of getExtentofText so that browser behavior
>> (currently inconsistent) allows for alignment of tops of glyphs along
>> a common baseline. See [2] for details.

>getExtentOfChar is defined to return the glyph cell rectangle, not the
>extent of the glyph ink.  It sounds like you might want the latter?
>(The WG has previously discussed having a mode for getBBox that does
>look at ink rather than glyph cell rectangles for <text>.)


Yep! That's what I think I want. I want to know where the glyph as drawn actually sits. The reason I thought the spec may be unclear is that both Opera and ASV interpret it the way I wanted it. I don't really see the value of knowing the glyph cell rectangle. Isn't that a simple by-product of the font size? That is except for glyph width, FF, Webkit and IE9 all give the same glyph height for all characters in a font! That is rather uninteresting it seems, though they do measure the horizontal displacement and that can be quite handy, I suppose, for implementers doing the comparatively simple text on a curve stuff.

>> 2. A discussed here [3] & [4] , it would be nice to be able to flow
>> glyphs in a way that squeezes their shapes to conform to both a top
>> curve and a bottom curve. Such textual effects are surprisingly
>> common in advertising, logos, shop signs, music album covers and the
>> like, once one starts looking for them. Think of the WordArt effects
>> in Microsoft Word only considerably more flexible, scriptable, and
>> animatable. Squishing glyphs into convex polygons (such as in the
>> logos for "NFL", "HTML5" and "Bankers Box") requires non-affine
>> transforms, but those are already a part of 2.0 so should not too
>> major a headache.

>I like and want to have support for this effect, but it isn’t trivial.
>(You could do it with a displacement map, but transforming the vectors
>would be preferable.)  

Well, yeah sort of. Yes it would be preferable and almost necessarily vector based, but, even so,  confining shapes to polygons via displacement maps is far from trivial itself! My experiments here on attempting to do precision work of this sort have been largely unsuccessful. Has anyone thought about vector-based displacement maps so that the result is ultimately a vector? I suspect the math gets very gnarly in edge cases if not downright ugly. I'm imagining fractals and undecidable functions and the like.

>I’d like to see someone prototype it in
>JavaScript, but this would require access to the glyph shapes – we
>should expose this, too.

A fair deal. You expose access to shapes and I can round up some folks to work on prototyping! Just having access to the tight bounding box would suffice. But yes, I think some clear idea of where one is headed here would make sense. Start with piecewise deformations of glyphs from bounding boxes into bounding quadrilaterals that best conform to the slopes of the curves above and below at the midpoints? Transforming an L into something curvy at the bottom, or transforming the 5 in HTML5 into something strictly polygonal would take some true magic, but it would be fun magic, and largely solvable I think. I mean after all, lots of software is out there doing this sort of thing, and surely these effect that have been around in excess of 20 years can no longer be all encumbered by patents except for by the false claimants of alleged patents who by all that Emperor Maximilian in his grant of patent to Albrecht Durer deemed appropriate should result in severe threats of bodily harm from the rightful holders of said patents: the public '[1]

>> There is another advantage here and that is it may set the stage for
>> many typographical devices used in cartography in which not just text
>> but glyphs conform to bounding regions.

>Do you have an example of this?

Well lots of examples of said typographical devices at [2] but I'm hoping Yan Li, who has convinced me of relevance to cartography directly, can provide more in the paper we're preparing together for SVG Open! In the case of cartography, it seems there are attractors (like geo-features) which draw labels toward them, repellants (like other features and other labels) that repel glyphs within labels, and containers (like regions) that serve as absolute constraitns on the placement of glyphs. At the same time as doing all this, legibility must be preserved, and in multiple languages. What fun! But I think there are practical parts of this problem that can be solved without use of the entire Cloud and without the entire programming staff of both Google and Microsoft. 

In thinking broadly about the issue of fonts, accessibility, and geometry, before undertaking extensions to the SVG spec on fonts, which will admittedly be difficult (given how hard it has been to get browser agreement on the parts already in the spec) it would be good to look at some of the wilder things in the last few links at [3]. I'm trying to collect lots of more adventurous use cases and some are pretty remarkable. Calligrams and in particular some of the Arabic ones are very much semantic vectors, but incredibly fluid ones.

Regards
David

-- 
Cameron McCormack ≝ http://mcc.id.au/


[1] http://williampatry.blogspot.com/2005/09/albrecht-drer-and-copyright.html 
[2] http://srufaculty.sru.edu/david.dailey/svg/top-align.htm   see alignment of glyphs to a curve, a pair of curves or a shape
[3] http://srufaculty.sru.edu/david.dailey/svg/fontplay.htm

Received on Wednesday, 1 June 2011 02:24:19 UTC