source: trunk/docx4j/src/main/java/org/docx4j/openpackaging/parts/WordprocessingML/MetafilePart.java @ 1637

Revision 1637, 689 bytes checked in by jharrop, 10 months ago (diff)

Alberto's patch of 3 August.

  • The ConversionImageHandler?.handleImage is declared now as throwing a Doc4jException
  • I have removed the dependencies on vfs

If the ConversionImageHandler?.handleImage throws an Exception, it will be logged as an error in the AbstractWordXmlPicture?, but it won’t be propagated. I’m not sure, but I think that an exception in handleImage should not stop the conversion process.

Removing the dependencies on vfs:

org.docx4j.model.images.DefaultConversionImageHandler? has been replaced with the following hierarchy:

org.docx4j.model.images.AbstractConversionImageHandler?

-> org.docx4j.extras.vfs.VFSConversionImageHandler

-> org.docx4j.model.images.FileConversionImageHandler?

-> org.docx4j.convert.out.html.HTMLConversionImageHandler

-> org.docx4j.convert.out.pdf.viaXSLFO.PDFConversionImageHandler

  • VFSConversionImageHandler offers the old functionality based on VFS
  • FileConversionImageHandler? is based on plain File(s), this means that it won’t be able to handle such cases where the target directory is on an ftp-server (or something comparable).
  • HTMLConversionImageHandler. In HTMLSettings there is a new Setting ‘imageTargetURI’ that allows to define a prefix for the image URI. If it is set, HTMLConversionImageHandler will use it as an prefix for the image URI, otherwise the image URI will just be the image name. This behavior replaces fixImgSrcURL.
  • PDFConversionImageHandler will always use the absolute path of the file as the image URI.

Apart from this there is a new setting in AbstractConversionSettings? (‘imageIncludeUUID’) that allows to switch on or off the UUID (default is on)

org.docx4j.openpackaging.io.LoadFromVFSZipFile
org.docx4j.openpackaging.io.SaveToVFSZipFile and
org.docx4j.utils.VFSUtils

have been moved to org.docx4j.extras.vfs, there is no replacement for them.

org.docx4j.convert.in.Doc has been split in org.docx4j.convert.in.Doc (without convert(org.apache.commons.vfs.FileObject? in)) and org.docx4j.extras.vfs.VFSDoc (with the method)

org.docx4j.openpackaging.io.ExternalResourceUtils? now uses an URLConnection instead of VFS

If you put the stuff in org.docx4j.extras.vfs in docx4j-extras, you should be able to compile docx4j without the dependency on VFS.

Some additional changes:

  • A small detail: WordXmlPictureE20, checked blip.getEmbed() == null and blip.getLink() == null, but those getters would return an empty string.
Line 
1package org.docx4j.openpackaging.parts.WordprocessingML;
2
3import org.docx4j.openpackaging.exceptions.InvalidFormatException;
4import org.docx4j.openpackaging.parts.ExternalTarget;
5import org.docx4j.openpackaging.parts.PartName;
6
7public abstract class MetafilePart extends BinaryPartAbstractImage {
8       
9        public MetafilePart(PartName partName) throws InvalidFormatException {
10                super(partName);
11               
12                // Can't setContentType or setRelationshipType, since
13                // these will differ depending on the nature of the data.
14                // Common binary parts should extend this class to
15                // provide that information.
16               
17        }
18       
19        public MetafilePart(ExternalTarget externalTarget) {
20                super(externalTarget);
21        }       
22
23}
Note: See TracBrowser for help on using the repository browser.