Review Request 102716: Implement a playback device context for EMF and the start of an EMFPLUS parser.
Friedrich W. H. Kossebau
kossebau at kde.org
Thu Oct 2 17:11:16 BST 2014
> On Juli 6, 2014, 1:57 nachm., Friedrich W. H. Kossebau wrote:
> > Last work on the branch done more than 2 years ago (at least by commits visible in main repo), could we close this RR until it is seriously up for review again?
Ping?
- Friedrich W. H.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/102716/#review61712
-----------------------------------------------------------
On Sept. 27, 2011, 12:14 nachm., Inge Wallin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/102716/
> -----------------------------------------------------------
>
> (Updated Sept. 27, 2011, 12:14 nachm.)
>
>
> Review request for Calligra and Thorsten Zachmann.
>
>
> Repository: calligra
>
>
> Description
> -------
>
> This patch does two things:
> - It implements the concept of the Playback Device Context into libemf
> - It contains a start of an EMFPLUS parser.
>
> The device context is a struct of data that is kept during the playback of an EMF metafile. It contains graphics state variables like current colors (text, background, foreground), current brush, pen, raster operation, etc as well as some bigger things. Previously all this was kept in the QPainter backend that is used to paint the content of the EMF to a QPaintDevice.
>
> With the new explicit device context, that is kept by the parser, we get two advantages:
> 1. It is much easier to write new backends, so e.g. a karbon import filter for EMF will be almost trivial
> 2. We can implement EMFPLUS, which is the next generation EMF from Microsoft, since EMFPLUS demands transfer of device contexts.
>
> This patch is tested in every commit along the way, but only on a limited set of documents, by hand by me. the reason for this commit request is that Zagge promised to make a big cstester run if I put it up for review. I would like to merge this patch on thursday at the latest, since the tagging of beta2 is on friday.
>
> The new EMFPLUS parser is still work in progress and not called yet, so there is no real need to review that.
>
>
> Diffs
> -----
>
> plugins/vectorshape/CMakeLists.txt da25dbb
> plugins/vectorshape/VectorShape.cpp c14e6a7
> plugins/vectorshape/libemf/CMakeLists.txt 7824052
> plugins/vectorshape/libemf/EmfAbstractBackend.h PRE-CREATION
> plugins/vectorshape/libemf/EmfAbstractBackend.cpp PRE-CREATION
> plugins/vectorshape/libemf/EmfDebugBackend.h PRE-CREATION
> plugins/vectorshape/libemf/EmfDebugBackend.cpp PRE-CREATION
> plugins/vectorshape/libemf/EmfDeviceContext.h PRE-CREATION
> plugins/vectorshape/libemf/EmfDeviceContext.cpp PRE-CREATION
> plugins/vectorshape/libemf/EmfEnums.h 1b15344
> plugins/vectorshape/libemf/EmfOutput.h 7b247af
> plugins/vectorshape/libemf/EmfOutput.cpp df3332a
> plugins/vectorshape/libemf/EmfOutputDebugStrategy.h af3dc21
> plugins/vectorshape/libemf/EmfOutputDebugStrategy.cpp 4f1d87c
> plugins/vectorshape/libemf/EmfOutputPainterStrategy.h 8e37d42
> plugins/vectorshape/libemf/EmfOutputPainterStrategy.cpp fcf6822
> plugins/vectorshape/libemf/EmfPainterBackend.h PRE-CREATION
> plugins/vectorshape/libemf/EmfPainterBackend.cpp PRE-CREATION
> plugins/vectorshape/libemf/EmfParser.h f376dc2
> plugins/vectorshape/libemf/EmfParser.cpp a8d54fa
> plugins/vectorshape/libemf/EmfplusDeviceContext.h PRE-CREATION
> plugins/vectorshape/libemf/EmfplusDeviceContext.cpp PRE-CREATION
> plugins/vectorshape/libemf/EmfplusEnums.h PRE-CREATION
> plugins/vectorshape/libemf/EmfplusParser.h PRE-CREATION
> plugins/vectorshape/libemf/EmfplusParser.cpp PRE-CREATION
> plugins/vectorshape/libemf/TODO cde117e
>
> Diff: https://git.reviewboard.kde.org/r/102716/diff/
>
>
> Testing
> -------
>
> Testing all commits with a limited set of test files that I keep.
>
>
> Thanks,
>
> Inge Wallin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20141002/28661204/attachment.htm>
More information about the calligra-devel
mailing list