I am using pygtk and cairo (...wonderful stuff I must say. Thanks to all)
I am wondering how to present parts of images on my my cairo surface on a large drawingarea.
I would like to have areas within the displayed surface that appear to act clipped so I can scroll images through these areas without disturbing the surrounding drawn items.
Can I cut images for part drawing onto a surface or must I just get the drawing sequence in the proper order so that the images needing to be clipped are overlain and so part hidden as required and appear clipped?
thanks for any pointers
nick
Cairo is indeed wonderful! ctx.clip() is one way to do it, using a clipping path (shown below in just pycairo, where the final draw rectangle only hits the triangular clipped area).
You could also use a transfer mode of CAIRO_OPERATOR_OUT (I think), but I'm less familiar with the transfer modes. And that would only work on the first draw, since your content would fill the alpha a bit.
(Your suggestion of "Painting Order" will work fine, too, of course!)
import cairo
WIDTH, HEIGHT = 256, 256
surface = cairo.ImageSurface (cairo.FORMAT_ARGB32, WIDTH, HEIGHT)
ctx = cairo.Context (surface)
ctx.rectangle(0,0,300,300)
ctx.set_source_rgb(0,0,0)
ctx.fill()
ctx.move_to(0,0)
ctx.line_to(200,90)
ctx.line_to(90,200)
ctx.line_to(0,0)
ctx.close_path()
ctx.clip()
ctx.rectangle(0,0,300,300)
ctx.set_source_rgb(1,1,0)
ctx.fill()
surface.write_to_png("clipped.png")
Related
I am using pixel colour inspection to detect collisions. I know there are other ways to achieve this but this is my use case.
I draw a shape cloned from the main canvas on to a second canvas switching the fill and stroke colours to pur black. I then use getImageData() to get an array of pixel colours and inspect them - if I see black I have a collision with something.
However, some pixels are shades of grey because the second canvas is applying antialiasing to the shape. I want only black or transparent pixels.
How can I get the second canvas to be composed of either transparent or black only?
I have achieved this long in the past with Windows GDI via compositing/xor combinations etc. However, GDI did not always apply antialiasing. I guess the answer lies in globalCompositeOperation or filter but I cannot see what settings/filters or sequence to apply.
I appreciate I have not provided sample code but I am hoping that someone can throw me a bone and I'll work up a snippet here which might become a standard cut & paste for posterity from that.
I have an image that is generated as an NSImage, and then I draw it into my NSView subclass, using a custom draw() method.
I want to modify this custom view so that the image is drawn in the same place, but it fades out on the side. That is, it's drawn as a linear gradient, from alpha=1.0 to alpha=0.0.
My best guess is one of the draw() variants with NSCompositingOperation might help me do what I want, but I'm having trouble understanding how they could do this. I'm not a graphics expert, and the NSImage and NSCompositingOperation docs seem to be using different terminology.
The quick version: pretty much this question but on macOS instead of Android.
You're on the right track. You'll want to use NSCompositingOperationDestinationOut to achieve this. That will effectively punch out the destination based on the alpha of the source being drawn. So if you first draw your image and then draw a gradient from alpha 0.0 to 1.0 with the .destinationOut operation on top, you'll end up with your image with alpha 1.0 to 0.0
Because that punch out happens to whatever is already in the backing store where the gradient is being drawn to, you'll want to be careful where/how you use it.
If you want to do this all within the drawing of the view, you should do the drawing of your image and the punch out gradient within a transparency layer using CGContextBeginTransparencyLayer and CGContextEndTransparencyLayer to prevent punching out anything else.
You could also first create a new NSImage to represent this faded variant, either using the drawingHandler constructor or NSCustomImageRep and doing the same image & gradient drawing within there (without worrying about transparency layers). And then draw that image into your view, or simply use that image with an NSImageView.
I'm adding borders to various images in a .pdf document. The borders all have the same width, but in the .pdf the borders have different widths. It is more pronounced as the width of the border increases.
Also, is there a way to move the border outside of the image, so that it is not covering any of the image using the methods of the image class? I realize I can first put a filled rectangle and then add the image on top of the rectangle as an option. Just curious as to if this can be done with methods from the Image class.
Here is the code snippet
magazine.open();
canvas = pdfw.getDirectContent();
image = Image.getInstance("a.JPG");
image.setBorder(Rectangle.BOX);
image.scaleAbsolute(200,200);
image.setBorderWidth(50);
image.setAbsolutePosition(50,10);
//canvas.addImage(image);
magazine.add(image);
image = Image.getInstance("b.jpg");
image.setBorder(Rectangle.BOX);
image.scaleAbsolute(200,200);
image.setBorderWidth(50);
image.setAbsolutePosition(50,230);
//canvas.addImage(image);
magazine.add(image);
I fear you'll have to work with the workaround you described.
There are two ways to define a border for an image:
image.setUseVariableBorders(false);
This is the default. This is what you have (even though you aren't calling the method explicitly).
In this case, the thickness of the border is distributed in a way that half of the line width is inside the rectangle and half of the line width is outside of the rectangle. Maybe that's what's causing the effect that the difference you notice is more pronounced as the border width increases.
Then there is:
image.setUseVariableBorders(true);
Now the borders will be drawn inside the area needed for the image. This is useful for tables (both PdfPCell and Image are subclasses of the Rectangle class where these methods are defined), but I fear it doesn't help you in the case of images.
So your best chance is to add the border using a workaround.
I'm using GDI+ in my application, and I need to use a rotated LinearGradientBrush to paint several rects in the exact same way. However, although I'm calling the same code to fill each rect, the results aren't what I expect. Here's the code to create the gradient fill, where rcDraw is the rect containing the area to paint for each rect. These coordinates are in the parent window's coordinates, so they are not identical for the 2 rects.
g_hbrLinear = new LinearGradientBrush( Rect( 0, rcDraw.top, 0, rcDraw.bottom - rcDraw.top ),
clrStart, clrEnd, (REAL) 80, FALSE );
What I see on screen looks like this (http://www.nnanime.com/bugs/LinGradBrush-rotate10.png). You can see that it's as if the fill from the first rect continues into the second one. What I really want is to have the 2 rects look identical. I think I can do that if I paint each rect separately using its own client coordinates, but for the purposes of my app, I need to use the parent window's coordinates.
I guess what I'm asking is, how does GDI+ calculate the "origin" of a fill? Is it always based on 0,0 in the coordinate system you use? Is there a way to shift it? I tried TranslateTransform, but it doesn't seem to shift the fill in a way that I find predictable or understandable.
The rect passed to the linear gradient brush determines the where the left and right colors will sit, and the gradient will be painted within this rectangle.
So, I think you need to create a brush for each rectangle you are painting, where the rectangle you are painting is also passed to the constructor for the linear gradient brush.
My experience with the "transform" of linear gradient brushes matches yours; I haven't been able to understand what it's supposed to do.
You can think of a brush in GDI+ as a function mapping world co-ordinates to a color. What the brush looks like at a given point does not change based on the shape being filled.
It does change with the transform of the Graphics object you're drawing on. So, if you don't want to change the brush, you could temporarily change the transform of the Graphics object so that the rectangle you're drawing has a specific, known size and position in world coordinates. The BeginContainer and EndContainer methods should make this easy.
(There is also the RenderingOrigin property but it only affects hatch brushes, which oddly are unaffected by world transforms.)
Does anybody have any pointers on how to successfully draw a bitmap that has
an alpha channel using Graphics::DrawImage() when the Graphics context is
created based on a printer HDC? The printer drivers don't generally support alpha blending - so is there an alternative to rendering everything to an offscreen bitmap and just sending that to the printer. This is often not feasible, especially for high res printing to large format printers.
What kind of printer is that? Regular printers don't print white. Create in-memory image and 'flatten' it (remove alpha channel) and then print the result.
Have you tried drawing a white rectangle to initialize the image before you call the DrawImage method?
The whole point is that I need the line-drawn graphics behind the image to be visible. I did try filling the rectangle first the with RGBA color of (255, 255, 255, 0) but this does not help. Pixels with an alpha value of zero do get printed as fully transparent but partially transparent pixels are drawn fully opaque.
Thanks for asking this question because I was just thinking of perhaps trying to use GDIplus to see whether it could get me around the problems I'm still facing getting patterned diamond shapes to print correctly. Although nowadays alpha-blending does appear to work on most printers, there are still some that draw black corners on the diamonds.
Aside from alpha-blending, I've also tried using diamond-shaped clip regions to surround the shape, but normally the printers that don't support alpha-blending don't seem to support polygonal clip-regions either. I've tried copying from the printer-dc into a bitmap to prime it before drawing the diamond on top, hoping that this will allow me to put back (in the corners) what was there before. This doesn't work either because it appears that the problem boils down to the fact that the printer driver doesn't actually know what is being printed on what part of the page.
In my case, my next plan is to try using a large bitmap brush for drawing the diamond fill directly to the printer hdc. I suspect there's a moderate chance that this too will fail for certain printers. It sounds like it may not be an option for what you were doing.