Re: PDFMarkupAnnotations not showing when drawing PDFPage
Re: PDFMarkupAnnotations not showing when drawing PDFPage
- Subject: Re: PDFMarkupAnnotations not showing when drawing PDFPage
- From: Antonio Nunes <email@hidden>
- Date: Sat, 17 Feb 2007 13:06:27 +0000
On Feb 17, 2007, John Calhoun wrote:
On Feb 16, 2007, at 2:11 PM, Antonio Nunes wrote:
Aha, now we're getting somewhere: the results (whether for
strikeout or underline type) depend on the color, both in the
NSView and in the PDFView:
Why would that be though? What is it about the context of the
NSView that is any different than the context of the PDFView's
internal NSView? That's a mystery to me.
You ask such good questions! Looks like the veil of ignorance will
shroud us for a while longer. So maybe the question becomes what the
markup does to yield these strange results in a plain vanilla NSView,
and what PDFView does to correct it. That might make it unnecessary
to figure out the stuff below. Or not…who knows?
Try this:
- (void) drawWithBox: (CGPDFBox) box inContext: (CGContextRef) context
Ha, that's more like it. This call is charmingly functional when
drawing to screen, but doesn't get called when printing. I tried it
in my production code with the same results. The problem isn't with
the subclassing though: Neither my subclass, nor ordinary
PDFAnnotationXXX objects are printed, whether printing from either a
PDFView or my custom NSView subclass. I checked the page during
printing and the annotation objects are definitely present in the
page's object graph.
No problems using the multiply compositing mode on the vanilla NSView
though. I'm just guessing at a number of things in the following
code, but it appears to mimic the desired drawing behavior fairly well.
- (void) drawWithBox: (CGPDFBox) box inContext: (CGContextRef) context
{
// For a highlight we need to multiply the colors, otherwise we
leave the mode in peace
if ([self markupType] == kPDFMarkupTypeHighlight) {
CGContextSetBlendMode(context, kCGBlendModeMultiply);
}
// Fill with a calibrated RGB color space
CGContextSetFillColorSpace(context, getTheRGBColorSpace());
// Let's draw yellow for now
float yellow[4] = { 1.0, 1.0, 0.0, 1.0 };
CGContextSetFillColor(context, yellow);
// Set up the fill-rect emulating the superclass' behaviour (I hope).
CGRect rect;
NSRect nsRect = [self bounds];
float lineHeight = NSHeight(nsRect) / 20;
switch ([self markupType]) {
case kPDFMarkupTypeHighlight:
rect = CGRectMake(NSMinX(nsRect), NSMidY(nsRect) - (lineHeight *
6), NSWidth(nsRect), lineHeight * 12);
break;
case kPDFMarkupTypeStrikeOut:
rect = CGRectMake(NSMinX(nsRect), NSMidY(nsRect) - (lineHeight /
2), NSWidth(nsRect), lineHeight);
break;
case kPDFMarkupTypeUnderline:
rect = CGRectMake(NSMinX(nsRect), NSMinY(nsRect) - (lineHeight /
2), NSWidth(nsRect), lineHeight);
break;
default:
break;
}
// Duh! (No, really, would *you* like to leave out the following line?)
CGContextFillRect(context, rect);
}
I'm not sure if the strikeout and underline modes use the default
blend mode and I haven't thoroughly tested the height and placement
calculations of the actual drawing. They appear correct when drawing
boxes of various heights, coinciding nicely with the boxes the
superclass draws, but I wouldn't be surprised if the were
circumstances that could break this code. I also totally ignore the
PDF box in this test code. That may have to change when I transfer
this to a production environment. Any comments/corrections on the
implementation will be most welcome, even if just to say that it will
be fine as is.
Thanks,
António
----------------------------------------------------
It isn't so important to do great things,
as to do what you do with great love.
----------------------------------------------------
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden