Adobe SVG Viewer and caching

Michael and/or Jon, My font problems with SVG have made me watch the process of resizing graphics pretty closely. Each time I resize it looks as if the browser

Message 1 of 6
, Aug 20, 2000

0 Attachment

Michael and/or Jon,

My font problems with SVG have made me watch the process of resizing graphics
pretty closely. Each time I resize it looks as if the browser goes back to
Adobe.com for each part of the graphic.

As far as I can tell from observation and timing there is little or no
caching of components of an SVG file implemented in the June 2000 version of
the Adobe SVG Viewer. Is that correct?

The Candidate Recommendation refers to facilitating / maximising caching. Is
this something which is planned for a future version of the Adobe Viewer?

Andrew Watt

Michael Bierman

Andrew, I assume you happened to be talking about an SVG image from Adobe.com? In any event, resizing does not require going back to the server (wherever it

Message 2 of 6
, Aug 20, 2000

0 Attachment

Andrew,

I assume you happened to be talking about an SVG image from Adobe.com? In
any event, resizing does not require going back to the server (wherever it
may be). There are some performance issues with redraw in general that we're
going to address in a future release of the Adobe SVG Viewer.

As far as I know, you are correct, there's little caching of components in
our current SVG Viewer.

> -----Original Message-----
> From: AndrewWatt2001@... [mailto:AndrewWatt2001@...]
> Sent: Sunday, August 20, 2000 2:46 PM
> To: svg-developers@egroups.com
> Subject: [svg-developers] Adobe SVG Viewer and caching
>
>
> Michael and/or Jon,
>
> My font problems with SVG have made me watch the process of
> resizing graphics
> pretty closely. Each time I resize it looks as if the browser
> goes back to
> Adobe.com for each part of the graphic.
>
> As far as I can tell from observation and timing there is little or no
> caching of components of an SVG file implemented in the June 2000
> version of
> the Adobe SVG Viewer. Is that correct?
>
> The Candidate Recommendation refers to facilitating / maximising
> caching. Is
> this something which is planned for a future version of the Adobe Viewer?
>
> Andrew Watt
>
>
>
>
>
>

<< I assume you happened to be talking about an SVG image from Adobe.com? In
any event, resizing does not require going back to the server (wherever it
may be). There are some performance issues with redraw in general that we're
going to address in a future release of the Adobe SVG Viewer.

As far as I know, you are correct, there's little caching of components in
our current SVG Viewer. >>

Hi again Michael,

Thanks for your prompt reply.

On my machine at least it seems pretty clear that it *is* going back to the
server to resize - or at least it does for some parts of the image. Let me
explain why I think that is the case.

I continue to use it because it has the big delay on rendering the text
"Scalable Vector Graphics". ... Anyway, if I resize online then,
reproducibly, with either IE5.5 or Netscape 4.7 the text "Scalable Vector
Graphics" will render but only after a delay of several seconds and also
after the status bar of the browser gives a message indicating connection to
Adobe.com.

If I come offline and try to resize then, again reproducibly, all of the
image will render apart from the "Scalable Vector Graphics" piece of text -
it stays fixed in the gobbledegook stage. There is no error message - I guess
that is because of the way SVG handles errors, according to the CR.

So, as far as I can see, the browser does go back to Adobe.com - to pick up
something from the server. My guess is that it is the .cef files which Wade
mentioned yesterday.

Again, I am following this point through to try to improve my understanding
of what is happening with the rendering of fonts from non-Adobe sites which,
even online, stay as gobbledegook on my machine. My machine, for whatever
reason, needs to go back to the server for the Adobe.com image to resize the
offending piece of text. If I could understand what my machine lacks for
that, I might be one step nearer understanding what I need to do to fix the
problems with fonts I am having on some pages on a number of other SVG sites.

Andrew

Michael Bierman

Andrew, In a case like this, you re right we may be going back to the host computer (wherever that may be) because we don t cache the font. In the case where

Message 4 of 6
, Aug 21, 2000

0 Attachment

Andrew,

In a case like this, you're right we may be going back to the host computer
(wherever that may be) because we don't cache the font. In the case where
you are loading (or reloading) a new SVG image, we release the font from
memory to avoid taxing the machine. In the case when you're resizing the
object it may be that we unnecessarily go back to the server to retrieve the
font. This may be avoidable and if so, I'll ask my Engineering team if they
can address this issue in an upcoming release.

When loading a new image or updating an image (through adding a DOM node for
example), there are ways to avoid this, such as keeping an object on the
page displaying the font. This can be hidden somewhere, such as type with a
white fill and stroke on a white background.

One of the significant advantages of SVG is the ability to choose any font
you like--whether it resides on the user's machine or not. This can be
accomplished with SVG fonts (which are just outlines) or through the CEF
format (which includes hinting and kerning just as the parent TrueType or
Type1 font that created the CEF). Because of the progressive rendering, this
may, momentarily, cause the text to render in the wrong type face. I believe
this is the correct behavior according to the SVG spec unless the external
resource is specified by the author as essential as I posted earlier.

> -----Original Message-----
> From: AndrewWatt2001@... [mailto:AndrewWatt2001@...]
> Sent: Monday, August 21, 2000 12:20 AM
> To: svg-developers@egroups.com
> Subject: Re: [svg-developers] Adobe SVG Viewer and caching
>
>
> In a message dated 21/08/00 07:32:26 GMT Daylight Time,
> mbierman@...
> writes:
>
> << I assume you happened to be talking about an SVG image from
> Adobe.com? In
> any event, resizing does not require going back to the server (wherever it
> may be). There are some performance issues with redraw in general
> that we're
> going to address in a future release of the Adobe SVG Viewer.
>
> As far as I know, you are correct, there's little caching of components in
> our current SVG Viewer. >>
>
> Hi again Michael,
>
> Thanks for your prompt reply.
>
> On my machine at least it seems pretty clear that it *is* going
> back to the
> server to resize - or at least it does for some parts of the
> image. Let me
> explain why I think that is the case.
>
> The page I am viewing is
> http://www.adobe.com/svg/illustrator/example_svg.html
>
> I continue to use it because it has the big delay on rendering the text
> "Scalable Vector Graphics". ... Anyway, if I resize online then,
> reproducibly, with either IE5.5 or Netscape 4.7 the text "Scalable Vector
> Graphics" will render but only after a delay of several seconds and also
> after the status bar of the browser gives a message indicating
> connection to
> Adobe.com.
>
> If I come offline and try to resize then, again reproducibly, all of the
> image will render apart from the "Scalable Vector Graphics" piece
> of text -
> it stays fixed in the gobbledegook stage. There is no error
> message - I guess
> that is because of the way SVG handles errors, according to the CR.
>
> So, as far as I can see, the browser does go back to Adobe.com -
> to pick up
> something from the server. My guess is that it is the .cef files
> which Wade
> mentioned yesterday.
>
> Again, I am following this point through to try to improve my
> understanding
> of what is happening with the rendering of fonts from non-Adobe
> sites which,
> even online, stay as gobbledegook on my machine. My machine, for whatever
> reason, needs to go back to the server for the Adobe.com image to
> resize the
> offending piece of text. If I could understand what my machine lacks for
> that, I might be one step nearer understanding what I need to do
> to fix the
> problems with fonts I am having on some pages on a number of
> other SVG sites.
>
> Andrew
>
>
>
>
>
>

Chris Lilley

... I just tried out that page, resizing both online and offline, and confirm that the font is being requested on each resize. ... Right. If there was a cache,

Message 5 of 6
, Aug 31, 2000

0 Attachment

Michael Bierman wrote:

>
> Andrew,
>
> In a case like this, you're right we may be going back to the host computer
> (wherever that may be)

I just tried out that page, resizing both online and offline, and confirm
that the font is being requested on each resize.

> because we don't cache the font.

Right. If there was a cache, the request would still happen, but would be
satisfied immediately and would continue to work when offline.

> In the case where
> you are loading (or reloading) a new SVG image, we release the font from
> memory to avoid taxing the machine.

Yes, that is the correct thing to do. It is odd that when resizing, the
font also seems to be released.

> In the case when you're resizing the
> object it may be that we unnecessarily go back to the server to retrieve the
> font. This may be avoidable and if so, I'll ask my Engineering team if they
> can address this issue in an upcoming release.

Since the plugin/control bypasses the browser cache, having its own cache
would be the easiest way to deal with this I suspect. It would also help
with reused images, symbols, etc.

> One of the significant advantages of SVG is the ability to choose any font
> you like--whether it resides on the user's machine or not. This can be
> accomplished with SVG fonts (which are just outlines) or through the CEF
> format (which includes hinting and kerning

SVG fonts also include kerning. I agree that they have no hinting.

> just as the parent TrueType or
> Type1 font that created the CEF). Because of the progressive rendering, this
> may, momentarily, cause the text to render in the wrong type face.

Yes, I can confirm that it does. However, I can't reproduce the 'several
seconds' delay. I see less than a second of delay (clearly this depends on
network traffic, butthenagain I am connecting over a single channel ISDN
line (64kbits/sec) to my ISP, and then traversing France, the Atlantic, and
the USA to get to this server. I see less thana second delay, and a very
brief burst of network activity where the request is bigger than the
response. It might be that the plugin is doing a HEAD or GET .. If Modified
Since request, which would result in a very brief response of the form, "no
the resource didn't change".

> I believe
> this is the correct behavior according to the SVG spec unless the external
> resource is specified by the author as essential as I posted earlier.

Yes.
--
Chris

Paton J. Lewis

... It appears to be the case that Netscape doesn t track URL requests made by plug-ins, so that when a plug-in asks for a resource again, Netscape doesn t

Message 6 of 6
, Sep 1, 2000

0 Attachment

At 02:47 PM 8/31/00 +0200, Chris Lilley wrote:

>
>
>
>Michael Bierman wrote:
> >
> > Andrew,
> >
> > In a case like this, you're right we may be going back to the host computer
> > (wherever that may be)
>
>I just tried out that page, resizing both online and offline, and confirm
>that the font is being requested on each resize.
>
> > because we don't cache the font.
>
>Right. If there was a cache, the request would still happen, but would be
>satisfied immediately and would continue to work when offline.

> > In the case where
> > you are loading (or reloading) a new SVG image, we release the font from
> > memory to avoid taxing the machine.
>
>Yes, that is the correct thing to do. It is odd that when resizing, the
>font also seems to be released.

It appears to be the case that Netscape doesn't track URL requests made by
plug-ins, so that when a plug-in asks for a resource again, Netscape
doesn't realize that the resource is already in its cache.

Pat

> > In the case when you're resizing the
> > object it may be that we unnecessarily go back to the server to
> retrieve the
> > font. This may be avoidable and if so, I'll ask my Engineering team if they
> > can address this issue in an upcoming release.
>
>Since the plugin/control bypasses the browser cache, having its own cache
>would be the easiest way to deal with this I suspect. It would also help
>with reused images, symbols, etc.
>
> > One of the significant advantages of SVG is the ability to choose any font
> > you like--whether it resides on the user's machine or not. This can be
> > accomplished with SVG fonts (which are just outlines) or through the CEF
> > format (which includes hinting and kerning
>
>SVG fonts also include kerning. I agree that they have no hinting.
>
> > just as the parent TrueType or
> > Type1 font that created the CEF). Because of the progressive rendering,
> this
> > may, momentarily, cause the text to render in the wrong type face.
>
>Yes, I can confirm that it does. However, I can't reproduce the 'several
>seconds' delay. I see less than a second of delay (clearly this depends on
>network traffic, butthenagain I am connecting over a single channel ISDN
>line (64kbits/sec) to my ISP, and then traversing France, the Atlantic, and
>the USA to get to this server. I see less thana second delay, and a very
>brief burst of network activity where the request is bigger than the
>response. It might be that the plugin is doing a HEAD or GET .. If Modified
>Since request, which would result in a very brief response of the form, "no
>the resource didn't change".
>
> > I believe
> > this is the correct behavior according to the SVG spec unless the external
> > resource is specified by the author as essential as I posted earlier.
>
>Yes.
>--
>Chris
>
>
>
>