 |
History
| Log In
|
|
|
|
Ready to apply your patch, but I seem to be missing:
ImageUtilities.createBufferedImage Sorry ... simply forgot the "svn diff" for the base trunk.
BTW: what do you think about moving the drawing from the method EMFRenderer.map(Tag, Graphics2D) to a new method EMFTag.map(EMFHandler). This method should contain nothing in the base class and has to be overloaded be the subclasses, e.g. AlphBlend. Subclasses are responsible for there own drawing. Doing so would led to a simple call of tag.map(this) in the EMFRenderer and remove that huge map(Tag, Graphics2D) method. EMFRenderer will still be responsible for storing the persistent informations (clippings, current figure and path etc.). Let me know your thoughts, I'll do this stupid task :) Regards Steffen Applied both your diffs with some minor changes. Seems to compile fine now with new freehep-util.
Yes, please go ahead and make the suggested move. My question is if that method should be called "map". What does it map. Does it not just render the tag, or execute it, or display? Regards Mark EMF2SVG
======= - used a combination of SVGraphics2D and EMFRenderer - some wordart objects still show wrong background gradients, SVGGraphics2D needs a fix EMFRenderer =========== - fixed the drawing of embedded EMF, MWT_LEFTMULTIPLY must be set for ModifyWorldTransformation - fixed drawing if path has opened - renamed some local variables in EMFRenderer, added getters / setters for the EMFTags - moved the rendering functions to the gdi package, that was a lot of work ... - implemented inheritance to avoid code duplication EMFViewer ========= - fixed the file name display EMFInputStream ============== - removed IOException from constructors EMFragphics2D ============= - removed 2 not needed local variables Hi
just saw your patch. Will apply it tomorrow morning or tonight. However two remarks: 1. TestSuite already has TestRenderingHints at the alphabetically correct place. 2. We will need to move EMF2SVG to a separate module, since we cannot really have EMF depend on SVG. What if someone wrote a SVG2EMF converter, SVG would need to depend on EMF. So I suggest I will create a separate module with name freehep-graphicsio-converters which can depend on any/all graphicsio modules and we move EMF2SVG in there. I believe we already have another converter somewhere... Let me know Mark patch does not seem to work on file EMF2SVG.java. Could you attach full file here. Other files are ok.
@1: I still get merging conflicts after you checking in "my" changes. So sorry if this happens.
@2: We can get rid of the dependency and we can convert to all available formats by using "ExportFileTypeRegistry.getDefaultInstance(loader).get(format)" wouldn't this be better? Do the ExportFileTypes run without a GUI or do we get exceptions in a command-line-only environment because a window server isn't available? Regards Steffen @1: Every patch you hand me I need to "normalize line endings" to get something reasonable...I use MacOS X while I think you use windows. Not sure how to handle this...
@2: Sounds ok as well. EFT should work without the windows server. Checked in the patch, with deps on SVG for now. Feel free to change @2. EMFPanel
======== - fixed a NPE if the EMF file was not found AbstractArc ========= - added some inheritance - added SetArcDirection and an corresponding attribute in the EMFRenderer GDIComment =========== - fixed an error if length == 0 ModifyWorldTransform ================== - added MWT_IDENTITY (not tested) - added MWT_RIGHTMULTIPLY (tested and uncommented because the behaviour is wrong, not clear why) new functions =========== - RoundRect, IntersectClipRect @Mark: do you know what a 4 byte long AlphaDIBBlend (id = 115) contains? It seems to be a setting for a later call to AlphaBlend which is used for image embedding in powerpoint. Applied your latest patch. Revision 10377.
Did you do the part on ExportFileTypeRegistry.getDefaultInstance(loader).get(format), if so I can take out the dependency on SVG. I have no idea about the AlphaDIBBlend. Doc on EMF is not very readily available. Thanks again Mark sorry, not before the end of next week ...
Regards Steffen PrintColor
======== - fixed a NPE if setPaint(null) happens EMFConverter =========== - added an "EMF to anything" converter for the command line - the class works as good as the drivers, using some "complex" EMF files the vector graphic drivers can't hide their flaccidities no more :), e.g. try: EMFConverter testfile.emf testfile_testfile.emf EMF2SVG ======== - based on EMFConverter now AbstractPolyPolyline ================ - added rendering for the EMF tags PolyPolyline and PolyPolyline16, which is "often" used by Visio 2003 - made AbstractPolyPolygon a bit more generic StretchDIBits ========== - fixed a NPE EMF tags
======== - added AbstractClipPath as a parent for all clipping tags - added ExtSelectClipRgn - added InsideFrameStroke in AbstractPen for the handling of EMFConstants.PS_INSIDEFRAME - added CreateDIBPatternBrushPt for painting bitmap textures - added a case in EMFImageLoader for monochrome images, this still needs a fix - added a warning in SelectObject if the GDIObject was not found EMFRenderer =========== - fixed getBounds(), the mapModeTransformation is now commented out because it does not work. Maybe we can reactivate it later Whats is left to be done here is the removal of the dependency on svg from emf.
There is no dependency. EMF2SVG is based on EMFConverter which uses ExportFileType.exportToFile(...).
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
 |
New Feature
Resolved
Major
Major improvements for EMFRenderer
Did you have a look at EMF+ as well. I wrote a provisional driver for it on a branch in SVN, see one
of our forums. EMF+ is embedded in GDIComments.