Skip Menu |

This queue is for tickets about the PDF-API2 CPAN distribution.

Report information
The Basics
Id: 98543
Status: rejected
Priority: 0/
Queue: PDF-API2

People
Owner: Nobody in particular
Requestors: philperry [...] hvc.rr.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: miterlimit() return a value?
Date: Tue, 02 Sep 2014 11:29:58 -0400
To: bug-PDF-API2 [...] rt.cpan.org
From: Phil M Perry <philperry [...] hvc.rr.com>
PDF::API2 v2.022 Perl 5.16.3 Windows 7 severity: Wishlist In Content.pm, most methods that set some value also return whatever the current (updated) value is, regardless of whether the method call sets a new value. miterlimit()/meterlimit() is an exception to this. Certainly, once the user has called it to set a value, there is one available to return, although there may not be a clearly defined official default value (2 or 4?). If there is a default value, I would suggest that miterlimit() return the current value if given with no argument. In all these cases, it may not be all that useful to return the newly set value, as the calling program presumably already knows this value (it just passed it to the method). What might be more useful would be to return the OLD setting, before it's overwritten by the NEW setting. Right now, code needs to call a method twice if it wants to preserve the old setting -- once without an argument to return the old setting, and then once with an argument to set the new setting. With the change, a single call could do it: OLD = method(NEW). Would this break any existing code?
Subject: [rt.cpan.org #98543]
Date: Sun, 24 Jan 2016 13:07:28 -0500
To: bug-PDF-API2 [...] rt.cpan.org
From: Phil M Perry <philperry [...] hvc.rr.com>
I understand that miterlimit() (formerly meterlimit()) is something of a special case, as it's not explicitly set by PDF::API2. According to the PDF 1.7 spec (PDF32000_2008.pdf), the PDF default value is 10.0. I don't know if that's different from earlier PDF versions. As for other settings, what does the community think about always returning the OLD setting whenever a setting is changed? Would this break any existing code? It would be nice to not have to make two calls: one to retrieve the old setting, and one to change the setting. Note that not all settings are returned from calls -- only 21 of them (stream, poststream, font, fontset, fontsize, charspace, hscale (formerly hspace), wordspace, lead, rise, render, matrix, textmatrix, textlinematrix, fillcolor, strokecolor, translate, scale, skew, rotate, and apiistext. I don't know if there is any rhyme or reason behind this set, but perhaps a better starting point would be to ask why old settings are not returned for transform_rel, matrix_update, linewidth, linecap, linejoin, miterlimit, linedash, flatness, clip, shade, and textstate. To add a comment to this thread, just email bug-PDF-API2 [at] rt.cpan.org with subject line [rt.cpan.org #98543]. Note 1 space between org and #, and the [ ] around the whole subject. Nothing else. If you don't follow this format carefully, you will end up creating a new bug report! HTML formatting within the body of the comment does not work.
Most of the content calls return the content object, allowing calls to be chained.
Subject: [rt.cpan.org #98543]
Date: Fri, 19 Feb 2016 09:45:32 -0500
To: bug-PDF-API2 [...] rt.cpan.org
From: Phil M Perry <philperry [...] hvc.rr.com>
Show quoted text
>Most of the content calls return the content object, allowing calls to
be chained. Many don't. There seems to be no rhyme or reason to which calls return $self object, and which don't (of which some should be returning a setting value). I think there should be a conversation about what changes should be made to return an object or a setting value in a consistent manner, so that the user doesn't need to read the code to see what's going on and to find out if calls can be chained or settings are returned. It's not a high priority, but shouldn't be in the junk pile either.