Pattern brush

[anovy]

Hi,
I found these two problems with pattern brushes (i.e. created by CreatePatternBrush function):

1) They have invalid scale in resulting PDF file (too small size).

2) They are always transparent (white color is transparent), although there is no reason for such transparency (ROP mode).

Could you please check this matter?

[Tracker Supp-Stefan]

Hello Anovy,

Have you posted this topic in the correct forums? As I could not find any trace of "Pattern Brush" in the Drivers API SDK manual - so I suspect this one might not belong here.

Best,
Stefan

[anovy]

I hope I'm correct here. PD-XChange driver acts as Windows printer driver which translates GDI to PDF. And CreatePatternBrush is a Windows GDI function, which is incorrectly supported.

[Tracker Supp-Stefan]

Ok - thanks.

Will ask one of our devs to check this.

Best,
Stefan

[Ivan - Tracker Software]

Can you send me your pattern image and code snippet when you use it?
I cannot reproduce the issue on my test sample.

[Tracker Supp-Stefan]

Hello anovy,

While we are awaiting your sample I also make a ticket for this case:
#1253: Drivers API SDK: Pattern brush problem
So that we can ensure we have all the information on the case tracked correctly.

Best,
Stefan

[anovy]

Sorry for a delay, I'm still preparing a simple code example.

However the problem is quite simple. If you will make a brush pattern from a bitmap for example 32x32 point size and you will use it on a device context with straight mapping (MM_TEXT), then the pattern should be displayed on the device in 1:1 mode (each pattern sample should occupy 32x32 device points). And I cannot achive such behaviour with XChange printer.

Attached are 2 PDF samples.

The first is created with XChange PDF driver. The drawing is small size, low DPI (72 DPI), the device pixel size is 227x46 points, i.e. GetDeviceCaps(hdc, HORZRES) returns 227, GetDeviceCaps(hdc, VERTRES) returns 46 (hdc represents XChange printer). The rectangle is filled by pattern brush created from bimap of 8x9 pixels size. So the filled rectangle should contain aprox. 5 rows of pattern samples.

The second PDF sample shows the image with correct drawing.

[Ivan - Tracker Software]

I made a fix to set the size of pattern depends of used DPI. The fix will be available in the next build which should be released over this weekend.
Another problem - with transparency - I cannot reproduce. Do you?

[anovy]

Thanks. Please note that another bug is with pattern orientation. In the T_2.PDF you can see the correct orientation.

Regarding the trasparency I will place a reply later, it is a longer talking...

[anovy]

Hi again,
Regarding the pattern brush transparency:

It is some strange thing, because it seems it depends on resolution. If the PDF file is with 200 DPI or lower, then the pattern is not transparent. With 300 DPI or higher the pattern is created by XChange as transparent.

In the samples which I post here the pattern is black and white (B&W). The color background of the filled rectangle is drawn before the pattern is applied. So if the pattern is drawn as transparent, then the color background is visible. If the pattern is drawn as opaque, then the color background is not visible (completely covered by the pattern).

In Windows GDI the patterns are by default drawn as opaque (when the SetROP2 is R2_COPYPEN).

To achieve white transparency of a B&W pattern, I can simply use R2_MASKPEN (this works also in XChange).

If the pattern is colored (white+some color), then I must first apply its B&W mask with R2_MERGEPEN and then I can apply the original pattern with R2_MASKPEN as before (I don't know yet if this works in XChange, I will test this after the problem with pattern size will be solved).

Now please find attached 3 samples. The first shows image with correct drawing (pattern is opaque). The second sample is 200 dpi file created by XChange, pattern is opaque (correct). The last example is 300 dpi file created by XChange, pattern is transparent (incorrect). The only difference between these two samples is really in the resolution, otherwise both files were created exactly by the same process (by the same sequence of GDI functions).

Because this problem is so strange (it depends on the resolution or PDF file size or maybe on more other factors) it is hard to arrange a simple code example. So if you will agree I can again provide you with my application and relevant input data (as we did already before for another problems), so you can create these PDF files on your computer and so test the problem directly.

[Ivan - Tracker Software]

Because this problem is so strange (it depends on the resolution or PDF file size or maybe on more other factors) it is hard to arrange a simple code example. So if you will agree I can again provide you with my application and relevant input data (as we did already before for another problems), so you can create these PDF files on your computer and so test the problem directly.

Yes, please. Problem is related to ROPs, and because ROP operations are not supported in the PDF format directly, the driver detects ROPs are present and replaces them with other sequences, as it is not an 'exact science' sometimes it may do this incorrectly and may need modification/fine tuning.

[anovy]

OK, I will prepare the software and sample data for you, I will then send a download link and instructions directly to your e-mail.

[Paul - Tracker Supp]

Will you post here or email?

[Tracker Supp-Stefan]

Hello anovy,

We are working on some tickets in preparation for build 198 - and I am happy to tell you that I just got a confirmation from our devs that ticket 1253 is resolved and the fix will be avalable in build 198 later today.

Best,
Stefan

[anovy]

I tested the build 198. The results are better, but now the situation is oposite than before - the patterns are now bigger than they shoul be. I will e-mail directly to Ivan more samples and my application.

[Tracker Supp-Stefan]

Hi anovy,

Glad to hear that there is an improvement, and yes - what you are thinking of doing will definitely help in investigating the problem.

Best,
Stefan

[anovy]

Hi, any news here? Did Ivan receive the link to the test application and files? I e-mailed it directly to Ivan at 20th September.

[Tracker Supp-Stefan]

Hi anovy,

I asked Ivan for an update and he should post here shortly.

Best,
Stefan

[Tracker Supp-Stefan]

Hello Anovy,

Ivan told me that he needs a bit more time to investigate this, so I've made a ticket for him:
#1334: Pattern brush problem
But we are aiming for fixing this in the next build.

Best,
Stefan

[anovy]

Hi, any news here? Can I hope that the problem will be solved?

[Tracker Supp-Stefan]

Hi anovy,

In the ticket I see that this issue will be resolved in a future build - as it could not be resolved for the initial release.
I will check if we can provide a bit more details on this case!

Best,
Stefan