AW: Had to add changes from #i105377# to get the correct Metafile creations.
AW: Working on decomposition; got pretty far, looking for
MetaFloatTransparentAction now...

AW: Getting forward, but also detecting problems over problems; the newest is
that Metaactions have Move and Scale actions, but the implementations are wrong
since ever (!). Many Metaactions contain a Rectangle and the scale scales the
Size (!) which gives a negative size with negative scale. Is a negative size
good? You bet, it's NOT. The resulting Rectangle is wrong since Right() is
smaller than Left(). ARGH!
This is in the code since EVER. It would have never happened with using linear
algebra and/or a better Rectangle class. That's the reason i use a Rnge-Class in
basegfx; it cannot have wrong rectangle definitions.

What will break when i fix this...?

AW: Re-implemented the ::Scale methods at all MetaFile actions. Additionally,
for MetaFloatTransparentAction neither the ::move nor the ::Scale implementation
applied to the contained content MetaFile, added this.
I also checked this. Nonetheless, since i think the GraphicManager is the only
user of this, i decided to also change this at
GraphicPrimitive2D::create2DDecomposition. There, it is possible to not get the
Graphic from GraphicObject by using GetTransformedGraphic, but to suppress
mirroring. Instead, add mirroring to the object transformation.
GetTransformedGraphic is still needed for Bitmap AND Metafile since it will
apply the R/G/G/Hue/Sat/... etc. modifications.
Testing changes...

AW: Works as expected.
Working on ClipRegion stuff now. Needs to be imported to primitives as stacked
PrimitiveSequences which need to be embedded to a MaskPrimitive on Region change...

AW: Found a performance bottleneck in SdrGrafObj::operator= where the
GraphicObject::SetGraphic command is used. There was no support for setting an
already existing object, so i extended it to accept a hint value to an already
existing GraphicObject which is then used to avoid the GraphicID generation in
the GraphicManager. This boots time extremly, the ID generation was more than
70% of the interaction. ID generation of Metafiles is expensive since it needs
to stream the Metafile and calculates the ID from the binary file data.
BTW: The first ClipRegion'ed decomposition works, but i will have to
ckeck/enhance further...

AW: Started various actions, but main change is that i now added a place to
create test-content metafiles since it's not easy to get metafiles which contain
what is implemented currently. I can now add various actions and compare their
output on VCL with the primitive output.
Used test code to check functionality of the ClipRegion actions
META_CLIPREGION_ACTION, META_ISECTRECTCLIPREGION_ACTION,
META_ISECTREGIONCLIPREGION_ACTION and META_MOVECLIPREGION_ACTION. These work
well and are implemented to use the highest possible quality: They do use not
the Region bands, but B2DPolyPolygons where possible. The ClipRegion changes use
geometric solutions (from basegfx) to clip the Clip-PolyPolygons.

Now to META_WALLPAPER_ACTION...

AW: Wallpaper is pretty complex and the BitmapTiled fill uses PixelSize of the
Bitmap directly (!). This makes it hard to express as primitive since all other
BitmapFills are defined using the PrefMapMode/PrefSize settings of the Bitmap.
Looking for a solution...

AW. Added a WallpaperBitmapPrimitive2D to solve the Pixel-oriented scalings for
Wallpapers using Bitmap tiled fillings. Completely implemented and checked that
all WallpaperStyle definitions are correctly supported. META_WALLPAPER_ACTION
now completely supported.
The next big chapter will be all forms of text MetafileActions...

AW: Started an intensive testing cycle for the already implemented actions using
the mechanism to feed in actions i need. Checked (and corrected)
MetaPixelAction, MetaPointAction and MetaLineAction, all three with mechanisms
to collect together data where possible (e.g. points with same color, lines
which can be appended to a polygon, etc, all with taking care of the attributes,
too). Works well, but also shows that these tests are needed. Continuing tests...

AW: tested and did various corrections for all currently supported actions. 36
actions checked. Now for text...

AW: First version of text and decorated text creation from Text MetaFile actions
works not too bad; need to do some finetuning, though.

AW: Got pretty far now. I got testcases from SJ concerning all bugdocs of
emf/wmf files of last tasks and checked with most of them, works very well now
(always compared to the VCL-MetaFile rendering, there are still errors in the
emf/wmf importers when comparing withthe WIN32 default preview renderer from the
system).

I have now also implemented and tested with testcode the MetaTextLineAction. For
that, i had to isilate the primitive creation(s) for
overline/underline/strikethrough to own primitives. Works well.

The remaining, not yet implemented actions are:

META_STRETCHTEXT_ACTION:
Text that shall be stretched to agiven size, no DXArray given. Not used in any
case until now (i assertted all not-implemented actions). I think this action
will not need to be implemented currently.

META_TEXTRECT_ACTION:
Also never used, text in a TextRectangle. Would be hard to implement since on
this level we have no TextLayouter available.

META_EPS_ACTION:
I need to check where this one is used and try to construct cases. Not done yet.

META_COMMENT_ACTION:
I have not yet implemented this action by purpose; it contains (for own
Metafiles) pretty much extra-data for more complex shapes which will be used. In
implementing this last, it was(is possible to check full functionality of all
pure MetaFile actions, e.g. the gradient actions with full XOR-paint support.

Thus, open are:
META_COMMENT_ACTION and META_EPS_ACTION...

AW: META_EPS_ACTION is created by OutputDevice::DrawEPS, looking for callers...

AW: OutputDevice::DrawEPS only exists in VCKL itself, there is no caller at all.
Have to ask VCL team.
AW->HDU, PL: Does anyone know where DrawEPS() was ever used, if Metafiles with
that action may exist, and who may know about...?

Let me google that for you:

  /DEV300_m64/cppcanvas/source/mtfrenderer/
transparencygroupaction.cxx 	365 case META_EPS_ACTION:
implrenderer.cxx 	    [all...]
  /DEV300_m64/goodies/source/filter.vcl/eos2met/
eos2met.cxx 	302 case META_EPS_ACTION :
772 case META_EPS_ACTION :
    [all...]
  /DEV300_m64/binfilter/bf_svtools/source/filter.vcl/wmf/
svt_emfwr.cxx 	1044 case( META_EPS_ACTION ):
    [all...]
svt_wmfwr.cxx 	    [all...]
  /DEV300_m64/goodies/source/graphic/
grfmgr.cxx 	197 mbEPS = ( rMtf.GetActionCount() >= 1 ) && ( META_EPS_ACTION ==
rMtf.GetAction( 0 )->GetType() );
    [all...]
grfmgr2.cxx 	869 case META_EPS_ACTION:
    [all...]
  /DEV300_m64/svx/source/xml/
xmlgrhlp.cxx 	81 && ( rMtf.FirstAction()->GetType() == META_EPS_ACTION )
    [all...]
  /DEV300_m64/extensions/source/svg/
svgaction.cxx 	    [all...]
  /DEV300_m64/filter/source/svg/
svgwriter.cxx 	    [all...]
  /DEV300_m64/svtools/source/filter.vcl/wmf/
emfwr.cxx 	1056 case( META_EPS_ACTION ):
    [all...]
wmfwr.cxx 	    [all...]
  /DEV300_m64/filter/source/flash/
swfwriter1.cxx 	    [all...]
  /DEV300_m64/filter/source/pdf/
pdfexport.cxx 	    [all...]
  /DEV300_m64/sd/source/ui/view/
sdview3.cxx 	229 case META_EPS_ACTION:
    [all...]
  /DEV300_m64/goodies/source/filter.vcl/epict/
epict.cxx 	    [all...]
  /DEV300_m64/goodies/source/filter.vcl/eps/
eps.cxx 	    [all...]

Completed in 378 milliseconds

Served by OpenGrok

Most times EPS is only used on printers, however on the mac it can also be
output to the screen.

AW: Completed implementation, commited to hg and pushed to so-cwsserv02.
Updating to m54, building...
Need to check eps visualisation on mac when done, so added unxmacxi to the
environments...

AW. Resync to m54 done, checked EpsPaint. Corrected a small error there.
Checking divrese emf/wmf/metafile combinations again...

AW: Corrected problems with rotated EPS files (graphicobjects containing
Metafiles with a single MetaEPSAction) in the previews and wrote #i107046# for
furter neded enhancement.
Also found some EPS files where MetaTextRectAction is used in the replacement
actions (must be constructed at EPS import time...?), thus i will add an
implementation for it.

AW: Support for MetaTextRectAction was complicated; The problem with this action
is that it describes unlayouted text and the layout capabilities are in
EditEngine/Outliner in SVX. The same problem is true for VCL which internally
has implementations to layout text in this case. There exists even a call
OutputDevice::AddTextRectActions(...) to create the needed actions as
'sub-content' of a Metafile. Unfortunately i do not have an OutputDevice since
the interpreter tries to work without VCL AFAP. Since AddTextRectActions is the
only way as long as we do not have a simple text layouter available, i will try
to add it to the TextLayouterDevice isloation.
AW: Works well that way, a problem coming up is more that this actions
constructed from EPS import ise again a Font WIth Width/Height of 0 (Zero) (!).
I already had a mechanism to handle this in MetaFontAction, but the 'guessing'
(see comments there) collided with earlier test files. I had to use the target
MapUnit of the Metafile and convert the 'guessed' pixels to that unit.
That works well with the new and old cases, but requires to init that value at
the PropertyHolders correctly.
AW: Woks well, checking in changed version with MetaTextRectAction, thus the
only remaining action without implementation is MetaStretchTextAction.

AW: Set target and set to fixed.

AW: Checked in installed build, works as expected.

AW->WG: Please review. There is no fix review for this, it changes everything
what was visualized using Metafiles. This is e.g deactivated charts, but also
inserted emf/wmf files. I can offer You a collection of emf/wmf files from SJ
(the problematic ones) if You want.
Best test would be to play around with OLEs (especially charts) and inserted
graphics (especially non-bitmap formats).

Verified.

AW: Closing.