xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bishop, Michael W. CONTR J9C880" <Michael.Bis...@je.jfcom.mil>
Subject RE: Error importing Images into an image tag?
Date Tue, 06 Dec 2005 02:47:02 GMT
Hi Thomas and Tonny,
     These explanations make good sense.  I think assigning the URL object makes the most
sense for me.  I'm mimicking OpenOffice's technique of storing documents by putting all the
SVG/images/etc. into a ZIP file.  When you load a whiteboard file, it expands the zip to a
predetermined "temp" directory which is where I want to manipulate everything.  If I cast
to an SVGOMDocument and set the URL as the temp directory, that should solve all the problems.
 
Michael Bishop

________________________________

From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
Sent: Mon 12/5/2005 8:11 PM
To: batik-users@xmlgraphics.apache.org
Subject: RE: Error importing Images into an image tag?



Hi Michael,

"Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> wrote on
12/05/2005 03:13:36 PM:

> OK, this makes a little more sense.  I don't have an SVGOMDocument, I
> have an SVGDocument.  I imagine my SVGDocument is implemented as an
> SVGOMDocument.

    Yes, in Batik an SVGDocument is currently always some form of
SVGOMDocument.

> to create my base document.  I don't want to set the xml:base attribute
> of an object because I run into the same problem of embedding absolute
> paths in the program.

    Well you could remove it before you save the document.

> I can't have a relative path to "nothing" can I?

    You can (in fact it's what you already have).  The problem is
that with no notion of it's absolute location it has no way to
find anything relative to it.

> Here's what I don't understand:
>
> - If I load an SVG document from c:\, I don't have any XML telling the
> document it lives at c:\.

   Right, because the SAXSVGDocumentFactory set's the base URL when it
loads the document (call 'getURL()' on the document loaded this way,
you will get an absolute URL point to where it was loaded from, this
is standard DOM).

> - If I create a document in memory and save it to c:\, the in-memory
> document does not know about c:\.  I don't want to set its base URL to
> c:\ because it will break if I move it do d:\.

   Once again you could have the xml:base attribute only on the document
in memory (remove it before saving, and add it back).  Personally I
suggest providing the URL object with the absolute URL where you saved
it (or at least want it to behave like it was loaded from).

> - The first example doesn't have this problem.  How can I mimic the
> behavior of the first example?

   Cast your document to a Batik SVGOMDocument and call setURLObject.
You are already using Batik specific classes (SVGDOMImplementation)
so this extra bit of 'setup' shouldn't really be a problem.


> -----Original Message-----
> From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> Sent: Monday, December 05, 2005 2:42 PM
> To: batik-users@xmlgraphics.apache.org
> Subject: RE: Error importing Images into an image tag?
>
> Hi Michael,
>
>         batik.dom.svg.SVGOMDocument.setURLObject(URL url).
>
>      You can also often do it when constructing the Document the first
> time.
> Also you can use xml:base to set the base for URL resolution at any
> point
> in
> the Document object.
>
> "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> wrote on
>
> 12/05/2005 02:25:55 PM:
>
> > So, the real question is...
> >
> > If I have a document in memory, then save it to disk, how do I
> > communicate the "base URL" of the document on disk to the document in
> > memory?  I need to save a document, then tell the in-memory one "You
> > reside at this location."  Is there a way to do that?  Obviously when
> I
> > load the document from disk, the base URL information already exists.
> >
> > Michael Bishop
> >
> > -----Original Message-----
> > From: Bishop, Michael W. CONTR J9C880
> > [mailto:Michael.Bishop@je.jfcom.mil]
> > Sent: Monday, December 05, 2005 1:48 PM
> > To: batik-users@xmlgraphics.apache.org
> > Subject: RE: Error importing Images into an image tag?
> >
> > Argh, this IS still broken, but now in a new way.  Here's the
> situation:
> >
> > - User saves an SVG document to a directory.
> > - User chooses to "import" an image.
> > - Image is copied to the same directory as the SVG document.  (I
> > manually verified this)
> > - Image is linked via xlink:href="imagename.jpg"
> > - The "broken image" icon is shown in place of the image.
> > - User saves SVG document.
> > - User loads SVG document.
> > - Correct image is now shown.
> >
> > I ran into similar problems when I didn't save an attribute with the
> > name space and Batik "fixed" the problem when reloading the document.
> > In this situation, I have no idea.  In short, the document MUST
> > originally be loaded from the file system in order for images to work;
> > if I import images to documents I've loaded from the file system, it
> > works as expected.
> >
> > Michael Bishop
> >
> > -----Original Message-----
> > From: Bishop, Michael W. CONTR J9C880
> > [mailto:Michael.Bishop@je.jfcom.mil]
> > Sent: Monday, December 05, 2005 12:14 PM
> > To: batik-users@xmlgraphics.apache.org
> > Subject: RE: Error importing Images into an image tag?
> >
> > Right, that's why I was being explicit.  I didn't want to be missing
> > something common or obvious.  I just switched it back over to
> > "xlink:href" and it worked fine for both loading and saving.  I dunno
> > what changed precisely, but I was working with a number of code
> changes
> > at the same time.  Might've been something unrelated.
> >
> > Michael Bishop
> >
> > -----Original Message-----
> > From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> > Sent: Monday, December 05, 2005 6:09 AM
> > To: batik-users@xmlgraphics.apache.org
> > Subject: RE: Error importing Images into an image tag?
> >
> > Hi Michael,
> >
> > "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> wrote:
> >
> > > I didn't see a way to import images without it.  Both the document
> and
> >
> > the
> > > imported image reside in the same "temp" directory.
> > >
> > > If they both reside in the same directory, do I need a URL
> structure?
> >
> >    No, but if the document you are adding the image to doesn't have
> > a base URL (usually because it was created 100% from DOM or read from
> > a stream with no associated URL) then it won't be able to find the
> > temp directory that the 'other' image is in.  However this will not
> > cause the 'xlink:href' must be present error.  It will cause a broken
> > link image to be used in most cases.
> >
> > > I just specify imagename.png or imagename.jpg because it's in the
> same
> >
> > > directory as the SVG document.  Do I still need "file://"?
> >
> >    No.
> >
> > > I'm trying to use relative paths so files can be moved around.
> >
> >    This is a correct and good thing to do.  It wasn't clear that
> > they were in the same directory.  Many people try and use things
> > like "C:\blah\blah\icons\foo.png" as a 'URL'.  So I am sure Tonny
> > was just trying to rule out some of the more common mistakes.
> >
> > > From: Tonny Kohar [mailto:tonny@kiyut.com]
> >
> > > On Sat, 2005-12-03 at 02:10 -0500, Bishop, Michael W. CONTR J9C880
> > > wrote:
> > > > It's definitely relative; all the files are in the same directory.
> > It
> >
> > > doesn't complain about missing images, it just says I don't have the
>
> > tag.
> > > It's odd how one way works when placing an image and another works
> > when
> > > loading an SVG document.
> > > >
> > >
> > > Another thing to consider
> > >
> > > Is this newly created document at the runtime, or previously created
> > and
> > > loaded document.
> > >
> > > In case it is newly created document at the runtime, you need to set
> > > DocumentBase url, so that batik could resolve the path.
> > >
> > > Regards
> > > Tonny Kohar
> > > --
> > > Sketsa
> > > SVG Graphics Editor
> > > http://www.kiyut.com
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> batik-users-unsubscribe@xmlgraphics.apache.org
> > > For additional commands, e-mail:
> > batik-users-help@xmlgraphics.apache.org
> > >
> > >
> > > [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC]
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> batik-users-unsubscribe@xmlgraphics.apache.org
> > > For additional commands, e-mail:
> > batik-users-help@xmlgraphics.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org



Mime
View raw message