https://issues.apache.org/bugzilla/show_bug.cgi?id=51351
--- Comment #11 from Yegor Kozlov <ye...@dinom.ru> 2011-06-16 08:03:03 UTC ---
>
> Graphic handling won't be part of extractor code. It's a lot of additional
> code
> AND additional libraries like Apache Batik or even ImageMagic calls. Also file
> creation and cleaning up should be coded.
>
> So there is an empty processImage() method that should be implemented in
> subclass if anyone want image to be included in XSL FO.
> createExternalGraphic()
> and setImageProperties() are helper methods for those people.
I see, but we can provide default support for png/jpeg with minimum efforts! I
added the following code and it worked for me:
protected void processImage(Element currentBlock, boolean inlined,
Picture picture) {
byte[] bytes = picture.getContent();
String ext = picture.getMimeType();
if(ext.equals("image/jpeg") || ext.equals("image/png")){
File file = new File(picture.suggestFullFileName());
try {
// dump images in the work dir
FileOutputStream out = new FileOutputStream(file);
out.write(bytes);
out.close();
Element graphics =
createExternalGraphic(file.toURI().toASCIIString());
WordToFoUtils.setPictureProperties(picture, graphics);
currentBlock.appendChild(graphics);
} catch (IOException e){
e.printStackTrace();
}
}
}
I agree that handling other mimetypes is not trivial and may involve
third-party libraries, but jpeg and png are most commons and should be
supported by default.
Does it make sense for you?
Regards,
Yegor
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org
