Inkscape

Bug #988601
Comment #29

Comment 29 for bug 988601

Revision history for this message

David Mathog (mathog) wrote on 2012-08-30:

#29

test_libuemf.png Edit (64.6 KiB, image/png)

Concerning pattern and image fill...

The attachment shows the test_libuemf.emf from libUEMF v0.0.7 as viewed in WIndows XP Preview. About 1/3 of the way down on the left there is a sideways "chevron" and to the right of that are two rows of squares.

1. The first row of same sized squares is all EMF defined hatch patterns as FILL with black line as STROKE..
2. The second row of same sized squares is the same, except, after Text and BackGround colors have been changed. You can see that the last 4 "hatch" patterns depend on these settings within the EMF file. Not possible within inkscape though. So when they are read in by Inkscape the object gets the current color, and when written back to EMF they stay with that color, that is, the color is not longer a function of Text/BackGround settings.

3. The third row of expanding squares is a bitmap fill using a color image using the EMR_CREATEDIBPATTERNBRUSHPT record type. The pattern is the same one used for the larger bitmap tests further down the page. The last square in that row, which is "Fuchsia" (ff00ff) is the same bitmap using the EMR_CREATEMONOBRUSH record instead. This combination is broken in all viewers and always shows a solid Text Color, so that is how Inkscape handles it as well.

4. The fourth row of expanding squares is a monochrome bitmap fill using the EMR_CREATEMONOBRUSH record . One color maps to Text and the other BackGround (Aqua, 00FFFF). The last square in that row is the same monochrome bitmap using insted the EMR_CREATEDIBPATTERNBRUSHPT record. This shows the two colors in the bitmap, that is, it does not remap to the Text/Bk color.

5. To the right of (1) and (2) is a series of line segments. The stroke is set with the allowed EMF hatch patterns and there is no fill.

6. To the right of (3) and (4) is a another series of line segments. For each position a thin black line is drawn first. There are a lot variables affecting the stroke over the wider line that overlays it. The left group of 6 uses a color bitmap, the right group of 6 uses a monochrome bitmap. Positions (as letters A-F) vs. EMR record types are:
A,B U_BS_DIBPATTERN
C,D U_BS_DIBPATTERNPT
E,F U_BS_PATTERN
Finally, A,C,E are drawn as solid lines, whereas B,D,F are dashed.

No EMF viewer could handle the dashed image fill, yet the EMF standard does not seem to exclude it. Inkscape reads records like that and drops the dash, so when this test image is viewed in Inkscape A==B, C==D and so forth.

The 3 bitmap stroke types sort of have the same behavior as the 2 bitmap fill types.

On EMF export if Inkscape sees a pattern, but cannot identify it as one of the EMFhatch# it will fill/stroke with a hatch pattern and color FFC3C3.

PowerPoint is miserably bad at importing these sorts of records into Microsoft Draw Objects. They look fine when Paste Image (from file) - because they are still basically a GDI drawing and PowerPoint doesn't mess them up. However, ungroup twice, to convert to Microsoft Draw Objects, and the only ones that work at all are the standard EMF hatch patterns. When those are imported the foreground is right, but the background color goes to black for FILL and to white for STROKE. This seems to be because Microsoft Draw Objects of these types must have a background color - "nothing" is not an option. The hatch fill/stroke do not specify one, so they just put black in. (Note that they are clearly not the EMF defined Text or Background colors, as those are Aqua and Fuchsia in this example.) There is an option in the EMF export dialog to convert everything that isn't one of the EMF hatches (bitmap fills, for instance) to one of the standard EMF hatches. These all map to the EMF cross hatch pattern with color FFC3C3.

Concerning pattern and image fill...

The attachment shows the test_libuemf.emf from libUEMF v0.0.7 as viewed in WIndows XP Preview.   About 1/3 of the way down on the left there is a sideways "chevron" and to the right of that are two rows of squares.

1. The first row of same sized squares is all EMF defined hatch patterns as FILL with black line as STROKE..
2. The second row of same sized squares is the same, except, after Text and BackGround colors have been changed.  You can see that the last 4 "hatch" patterns depend on these settings within the EMF file.  Not possible within inkscape though.  So when they are read in by Inkscape the object gets the current color, and when written back to EMF they stay with that color, that is, the color is not longer a function of Text/BackGround settings.

3.  The third row of expanding squares is a bitmap fill using a color image using the EMR_CREATEDIBPATTERNBRUSHPT record type.  The pattern is the same one used for the larger bitmap tests further down the page.  The last square in that row, which is "Fuchsia" (ff00ff) is the same bitmap using the EMR_CREATEMONOBRUSH record instead.  This combination is broken in all viewers and always shows a solid Text Color, so that is how Inkscape handles it as well.

4.  The fourth row of expanding squares is a monochrome bitmap fill using the EMR_CREATEMONOBRUSH record .  One color maps to Text and the other BackGround (Aqua, 00FFFF).  The last square in that row is the same monochrome bitmap using insted the EMR_CREATEDIBPATTERNBRUSHPT record.  This shows the two colors in the bitmap, that is, it does not remap to the Text/Bk color.

5.  To the right of (1) and (2) is a series of line segments.  The stroke is set with the allowed EMF hatch patterns and there is no fill.

6.  To the right of (3) and (4) is a another series of line segments.  For each position a thin black line is drawn first.  There are a lot variables affecting the stroke over the wider line that overlays it.  The left group of 6 uses a color bitmap, the right group of 6 uses a monochrome bitmap.   Positions (as letters A-F) vs. EMR record types are:
A,B U_BS_DIBPATTERN 
C,D U_BS_DIBPATTERNPT
E,F U_BS_PATTERN 
Finally, A,C,E are drawn as solid lines, whereas B,D,F are dashed.

No EMF viewer could handle the dashed image fill, yet the EMF standard does not seem to exclude it.  Inkscape reads records like that and drops the dash, so when this test image is viewed in Inkscape A==B, C==D and so forth.

The 3 bitmap stroke types sort of have the same behavior as the 2 bitmap fill types.

On EMF export if Inkscape sees a pattern, but cannot identify it as one of the EMFhatch# it will fill/stroke with a hatch pattern and color FFC3C3.

PowerPoint is miserably bad at importing these sorts of records into Microsoft Draw Objects.  They look fine when Paste Image (from file) - because they are still basically a GDI drawing and PowerPoint doesn't mess them up.  However, ungroup twice, to convert to Microsoft Draw Objects, and the only ones that work at all are the standard EMF hatch patterns.  When those are imported the foreground is right, but the background color goes to black for FILL and to white for STROKE.    This seems to be because Microsoft Draw Objects of these types  must have a background color - "nothing" is not an option.  The hatch fill/stroke do not specify one, so they just put black in.   (Note that they are clearly not the EMF defined Text or Background colors, as those are Aqua and Fuchsia in this example.) There is an option in the EMF export dialog to convert everything that isn't one of the EMF hatches (bitmap fills, for instance) to one of the standard EMF hatches.  These all map to the EMF cross hatch pattern with color FFC3C3.