Skip Menu |

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

Report information
The Basics
Id: 98544
Status: resolved
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: 2.026



Subject: enhancements to linedash() method
Date: Tue, 02 Sep 2014 11:41:14 -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 The linedash() method in Content.pm allows up to two lengths for "on" and "off" dashed lines. The PDF spec, while limited to one set of on/off lengths, also permits a starting offset (in points) into the linedash array. It might be useful to allow an optional additional parameter on the linedash() method, to give a starting offset and pass it to PDF. PDF limits dashed lines to two lengths (on, off). We should consider adding an enhanced linedash() method that permits more than two lengths, possibly permitting a very complex line pattern. It could even have additional parameters to change linewidth and strokecolor over the course of a pattern, and even include characters and symbols! At the PDF::API2 level, the line produced would have to be broken down into a number of more basic calls, and "bent" around corners (who knows what can be done on curved lines!). Thus, it would not be a trivial exercise. There are some optional hash parameters in linedash() whose purpose is unclear (and undocumented). Perhaps someone started on this enhanced linedash some time ago?
Subject: [rt.cpan.org #98544]
Date: Mon, 25 Jan 2016 10:28:46 -0500
To: bug-PDF-API2 [...] rt.cpan.org
From: Phil M Perry <philperry [...] hvc.rr.com>
A simple enhancement to the existing linedash(), for an optional "offset" value, would be a good match to the PDF primitive, and thus warranted. The more elaborate extensions, such as longer dash patterns, colors, lineweights, arrowheads, text, etc. might be better off in a new call. Consideration should be given to a more general design that accepts a path, and draws the complex "line" on it. Whether this could be integrated into existing line path routines, or requires duplicating them, is a topic for discussion. It might even be complicated enough to warrant a whole new package PDF::API2::Line! Does anyone have any record or recollection of what the (undocumented) %opts parameters were intended to do? To add a comment to this thread, just email bug-PDF-API2 [at] rt.cpan.org with subject line [rt.cpan.org #98544]. 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 does not work.
The linedash method already supports an offset and more than two lengths; it just wasn't documented very well. Your other requests are outside of scope for PDF::API2. They can be created as add-on distributions that make use of the lower-level calls provided by this one.
Subject: [rt.cpan.org #98544]
Date: Thu, 18 Feb 2016 16:18:36 -0500
To: bug-PDF-API2 [...] rt.cpan.org
From: Phil M Perry <philperry [...] hvc.rr.com>
Show quoted text
>The linedash method already supports an offset and more than two lengths; >it just wasn't documented very well.
I will hold on to this one and come up with an improved POD entry, if I can find the support in the code (and you don't beat me to the punch in doing it). Show quoted text
>Your other requests are outside of scope for PDF::API2. They can be >created as add-on distributions that make use of the lower-level calls >provided by this one.
I can live with it being a PDF::API2-subsidiary package. There's certainly enough function there to warrant a whole new package!
Subject: [rt.cpan.org #98544]
Date: Mon, 22 Feb 2016 11:35:57 -0500
To: bug-PDF-API2 [...] rt.cpan.org
From: Phil M Perry <philperry [...] hvc.rr.com>
| The linedash method already supports an offset and more than two lengths; it just wasn't documented very well. That's putting it mildly! I see you recently added an example to the POD for using -pattern and -shift. The PDF documentation is somewhat lacking, too, in that it only shows 0, 1 or 2 lengths, when in fact it will handle an arbitrary number of elements. I will extend the POD to cover the following: 1. 0 (solid line) or more numeric elements or -pattern elements are permitted, allowing a varied dash/space pattern. 2. An odd number of elements, either via the numeric list or -pattern, is allowed. It is repeated by the PDF processor, so 3,5,7 is the same as 3,5,7,3,5,7 or 2 is the same as 2,2. 3. -shift is not available for the numeric list, at least not without some ugly finagling with the code (it's probably not worth it, as the hash method is available). Since an odd number of element lengths is permitted, we can't do something like "if an odd number of on-off values is given, the last one is treated as the shift (offset)". To mix a variable-length array list with hash elements might be possible (e.g., linedash(2, 3, 5, 6, -shift=>4), but is likely to be messy code (extract pairs of hash elements from the array and put in own hash). At any rate, it doesn't work with the current code, and with the hash method available, it's probably not worth the effort. -full (dash length?) and -clear (gap length?) should be left undocumented, as they may be dropped at some time in the future. While I'm at it, should we put in some input data validation to ensure all lengths are positive numbers? I think that 0 is technically permitted (and -shift should allow 0), but doesn't make much sense for the on-off pairs. Negative lengths could cause problems and the PDF doc warns against using them. Finally, content.t needs updating with the hash format and lists longer than 2.