Loading ...
Sorry, an error occurred while loading the content.

Adobe SVG Viewer and caching

Expand Messages
  • AndrewWatt2001@aol.com
    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
    View Source
    • 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
      View Source
      • 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.

        ...............................
        Michael Bierman
        Senior Product Manager, SVG
        www.adobe.com/svg


        > -----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
        >
        >
        >
        >
        >
        >
      • AndrewWatt2001@aol.com
        In a message dated 21/08/00 07:32:26 GMT Daylight Time, mbierman@adobe.com writes:
        Message 3 of 6 , Aug 21, 2000
        View Source
        • 0 Attachment
          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
        • 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
          View Source
          • 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.

            Hope that helps.

            ...............................
            Michael Bierman
            Senior Product Manager, SVG
            www.adobe.com/svg


            > -----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
            View Source
            • 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
              View Source
              • 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
                >
                >
                >
                >

                ____________________________________________________________
                Paton J. Lewis
                Engineering Manager, SVG
                Adobe Systems
                206.675.7399
              Your message has been successfully submitted and would be delivered to recipients shortly.