Sounds like good changes to me! Leonard
On 11/26/13 3:11 PM, "Carlos Garcia Campos" <[email protected]> wrote: > >I've noticed some small issues in the way we handle the border of >annots compared to what the spec says and what acroread does. Attached >are 4 patches: > >[PATCH 1/4] annots: Remove unused AnnotBorderType from AnnotBorder > >This is simply a cleanup, we have a base class AnnotBorder that allows >to create instances of it with the unknown type. It doesn't make much >sense and we are not using it at all, so I've removed the >AnnotBorderType, and made the constructor protected. > >[PATCH 2/4] annots: Add helper function Annot::setLineStyleForBorder > >The code to set the line width and dash was duplicated in several draw() >methods, so I've moved it to a helper function. This patch also changes >the way we are using it. We were always ignoring the border when the >border with was 0, but it doesn't seem to be always correct. The PDF >spec says that in both Border and BS entries when the width is 0, no >border should be drawn at all. But some annotations like lines, >geometry, polygons, etc. don't use the border entry to actually draw a >border, but to set the line with and dash for the stroke operations. For >example, we were not drawing lines for annots with no border or with a >border width = 0, but acroread does, because in this case the border >entry is used to set the line with and dash pattern, and the PDF spec >also says that a line width of 0 should be drawn as the thinnest line that >can be rendered at device resolution: 1 device pixel wide. >So, for FreeText annotations where we actually draw a border, we only >call Annot::setLineStyleForBorder if we have a border and the width is >greater than 0, and in all other cases we always call it when we have a >border. Of course, this only affects annotations not having an AP entry. > >[PATCH 3/4] annots: Use a default border for annots that can have a BS >entry > >According to the PDF spec if neither the Border nor the BS entry is >present, the border shall be drawn as a solid line with a width of 1 >point. But again, acroread seems to only apply this rule for annotations >that can have a BS entry. This patch moves the parsing of the BS entry >From the base Annot class to the specific annot classes that can have a >BS entry, and it creates a default border object when neither Border nor >Bs is present. It also removes the border passed to Gfx::drawAnnot() in >AnnotFileAttachment::draw and AnnotSound::draw because acroread ignores >the Border entry also for annots that can't have a BS entry. >This ensures that we always draw line, geometry, polygon, etc, even if >there's no border specified. > >[PATCH 4/4] annots: Make Annot::setBorder receive an AnnotBorder object > >Currently we can only set AnnotBorderArray objects to annots. This might >have no effect if the annots already has a BS entry, for example, >because the BS takes precedence over Border. This patches changes >Annot::setBorder to receive an AnnotBorder object, so that you can >either pass an AnnotBorderArray or an AnnotBorderBS. Frontends should >always use BS when updating an annotation that can have BS entries. The >patch also completes the implementation of writeToObject method for >array borders and adds an impementation for BS borders too. > > >I've passed my tests with no regressions, but I can't test the qt >frontend (that uses setBorder(), for example), so it would be great if >someone could test these patches to make sure they don't introduce any >regression in qt (it should build in any case). > >Leonard, please, feel free to correct me if I'm wrong in any of my >interpretations of the PDF spec. > >Regards, _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
