Peter Thompson wrote:
> I need the capability to zoom without pixel replication. I don't
> know what the technical term for this is. The current SVG spec and
> SVG viewers don't support this directly. This subject has been
> written about in various threads and web sites, but I don't have a
> complete answer.
>
> The draft SVG spec version 1.2 has <vectorEffect> that will allow you
> to display a non-scaling line width, which will be an easy solution
> to part of the problem sometime in the future.
>
> I display lines, text, and symbols (<use> elements that link to
> <symbol> elements).
>
> It seems like there are two approaches:
> 1) Don't use SVG to do any scaling. That is, have the server
> generate a new SVG file for every scaling change (not a good solution
> due to the disruptive screen redraw) or go through the SVG DOM
> locally and modify all the x,y positions (probably takes too long).
> On previous generations of raster graphics systems, I have done
> things like redraw the rescaled picture in unviewable graphic planes,
> and then change the color map to swap viewable areas (which triggers
> a thought; perhaps I could use groups to perform a similar function).
>
> 2) Use SVG scaling capability to change the x/y positions and capture
> the onzoom event. When the onzoom event occurs, change the line
> stroke-width and text font-size inversely to current scale. This
> works pretty well, even though the lines look a little jaggedy at
> times (I haven't looked into this in detail; perhaps it is
> fixable). I haven't figured out a way to have non-scaling <use>
> elements that link to <symbols>. The display will have potentially
> 10,000 symbols displayed, maybe 20 different types of symbols,
> displayed in different groups so they can be hidden or change color
> under various (sometimes user-controlled) conditions.
>
> My preference is to follow approach #2. If I cannot figure out a
> good way to make the non-scaling symbology using the <use> elements,
> I could abandon that and switch to a font that contains the symbols.
> I think that approach may be promising.
>
> My questions are:
> 1. Any suggestions about creating non-scaling <use> elements that
> link to <symbols>?
> 2. Is it difficult to modify a font file?
Not at all, basically font glyphs are just made of SVG elements. Most of
the time, only path is used, but actually you can make something like:
<glyph unicode="d" glyph-name="d" horiz-adv-x="1024">
<circle cx="640" cy="640" r="600" fill="red"/>
<rect x="100" y="100" width="600" height="200" fill="blue"/>
</glyph>
The main problem is that for compatibility with existing font data, the
coordinates are upside-down, ie. y axis goes upward. I think it is easy
to write code to convert coordinates.
> 3. Any suggestions about a different approach for non-scaling symbols
> or to the whole problem?
No but another approach is to use markers as symbols. Somebody said it
was faster than real symbols (perhaps because there is less to parse and
path generation is highly optimized), and you don't have to use text
elements, which would infer with real text.
<defs>
<g id="Circles">
<circle cx="5" cy="5" r="4.5"/>
<circle cx="5" cy="15" r="4.5"/>
<circle cx="5" cy="25" r="4.5"/>
<circle cx="15" cy="10" r="4.5"/>
<circle cx="15" cy="20" r="4.5"/>
<circle cx="25" cy="15" r="4.5"/>
</g>
<marker id="ArrowCircles"
viewBox="0 0 30 30" refX="0" refY="15"
markerWidth="10" markerHeight="10"
markerUnits="userSpaceOnUse"
orient="-90">
<use xlink:href="#Circles" fill="blue" stroke="green"/>
</marker>
</defs>
<rect x="10" y="10" width="400" height="400"
fill="mediumspringgreen"/>
<path d="M 150,250 m -20,-15 m 15,-17 m 18,-20 m 15,14 m 17,25 z"
fill="none" stroke="white"
marker-mid="url(#ArrowCircles)"/>
This differs slightly from one of my previous posts as I use relative
moves (m) instead of relative linetos (l) with stroke-opacity to 0. It
may be faster and is conceptually more satisfying...
Of course, color of stroke has no importance, but it cannot be "none",
at least with ASV3, because nothing would be displayed.
orient attribute allows to have the same orientation, whatever the move was.
You still have to deal with re-scaling with script, alas. And perhaps it
is harder this way, as you must rescale markers, not path...
The main advantage is that the syntax is quite compact (even more with
removed whitespace), so the generated file is small, even with a lot of
symbols/markers.
--
Philippe Lhoste
-- (near) Paris -- France
-- Professional programmer and amateur artist
-- http://Phi.Lho.free.fr
-- For servers mangling my From and Reply-To fields,
-- please send private answers to PhiLho(a)GMX.net
-- -- -- -- -- -- -- -- -- -- -- -- -- --
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/1U_rlB/TM
--------------------------------------------------------------------~->
-----
To unsubscribe send a message to: [EMAIL PROTECTED]
-or-
visit http://groups.yahoo.com/group/svg-developers and click "edit my
membership"
----
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/svg-developers/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
