Posted by Kevin Karney on August 10, 2008 at 3:49pm
The PDF Library is great - I have used it a lot, but it has clearly been made for people writing reports with text and simple graphics.......
There does not appear to be any enhancements to the software in the last six months. Here is my list of needed improvements !
- Rotatable text (an absolute essential for engineering graphics)
- Ability to Clip and Mask (more or less essential)
- Ability to save a multi-point path
- All the current graphic parameters (fill & stroke colours, line thicknesses, etc) to be available as global parameters
- Ability to save and restore graphic states to a stack (a "graphic state" contains an origin, rotation, scale, fill & stroke colours and thicknesses, font, font size, current path and clipping path)
- Ability to draw a multi-point path with even dotting
Attached is a detailed engineering drawing prepared with the PDF Library, but note that the numbers and months had to be inserted afterwards with Illustrator
I hope we can see some (if not all) of these potential improvements.
Best regards
Kevin
Attachments:
Bifilar.pdf, 168 KB
=====
Reply by Jan Schenkel on August 12, 2008 at 8:02am
Hi Kevin,
Thank you for your feedback - it shows that you care as a frequent user of the library!
It is true that the last update has been a while - betwseen my day-job, the release and maintenance of Quartam Reports 1.1 and the development of new features and even completely new libraries, the PDF library hasn't received the attention it deserves.
Quartam PDF Library version 1.1 is under development and will cover a number of your requests but probably not all if we want to see it before the end of 2008. Let me go through your list:
- Rotatable text is just a special case of affine transformations so that's covered in 1.1
- Clipping is covered in 1.1 but could you elaborate on Masking?
- Multi-point path: what exactly are you looking to achieve that is currently impossible with the primitive commands (line, curve)
- Current graphic parameters: my plan was to add the equivalent 'get' function for every 'set' command; would that be sufficient?
- Save and restore graphic states is an interesting idea but I'll have to see how hard this is to add without upsetting the stability of the library in its current form
- Multi-point path with even dotting: could you elaborate on this?
Thank you for the engineering drawing - that is very impressive work indeed.
Best regards,
Jan Schenkel
--
Quartam Reports & PDF Library for Revolution
www.quartam.com
=====
Reply by Kevin Karney on August 12, 2008 at 1:29pm
Hi Jan
Thanks for your reply
- Rotatable text : excellent
- Masking is the opposite to Clipping. With Clipping, nothing is printed OUTSIDE the clipping path, with Masking, nothing is printed INSIDE the masking path.
- Multi-point paths. Yes, one can easily draw them using the primitives. To plot in a single primitive call is just easier. Especially if the line is dotted
- Current graphic parameters. Get & Set is fine, but it just strikes me that defining things as globals makes it easier - but then I know nothing of library programming
- The save and restore graphic states should be easy. On a Save, all the parameters get pushed onto a stack: on a Restore, the top of the stack is dropped. All plotting operations use whatever parameters are on the top of the stack
- I'll get back to you on dotted array lines. I need to tidy up my code !
Best regards
Kevin
=====
Reply by Jan Schenkel on August 12, 2008 at 9:03pm
Hi Kevin,
Thanks for the clarifications:
- After the reply, I glanced at the Adobe PDF reference document, and it linked Masking to clipping-with-transparency and blending; but what you're looking for is a way to 'invert' the clipping; I'll have to ponder that a bit.
- I can see where paths would come in handy; but it is once more going to need some pondering to get it just right; after all, the path should be re-usable for multiple purposes (clipping, plotting,...)
- The main reason to prefer Get & Set to global variables, is that global variables are very brittle; you can't really be sure that they'll contain correct data when you're going to use them; I had thought about using custom properties in the past, but even those can get messed up if the setProp/getProp handlers are blocked because of locked messages; so Get & Set is the way to go, I'm afraid
- Pushing graphic states onto a stack is another intriguing idea; but it may not be easy to insert into the library, as it is currently very 'stream-oriented' - every command that you execute is immediately recorded into a page buffer; I'm not saying it can't be done, but it's something that requires another round of pondering and careful testing to ensure it doesn't break anything.
Thanks again for the feedback!
Jan Schenkel
--
Quartam Reports & PDF Library for Revolution
www.quartam.com
=====
Reply by Kevin Karney on August 13, 2008 at 10:30am
Hi Jan,
If you really want to understand what's behind the pdf specification, you might like to look at the original Postscript documentation.
Postscipt was the brainchild of John Warnock (the founder of Adobe) who was a mathematical genius. His original mathematical concepts were the precursor to Postscript, PDF and all of modern digital printing technology.
In the Postscript docs, you can find all theory about stack based graphic states. Postscript is also strictly stream based.
The idea of pushing states onto a stack does not need to interfere with a stream based approach. It is just that the actual execution of writing to the page buffer will always use the origin/path/clip/fill colour/stroke colour/line thickness/scale/rotate parameters that are at the top of the stack.
The only area where the original mathematics (and the stream based writing approach) becomes somewhat unstuck relates to transparency of objects - since the image of what was previously rendered to the page must be remembered so that the transparent object can be correctly rendered on top of it. If my memory of history is correct, this (almost) alone is what caused PDF to be created to succeed Postscript.
Hope that this is of interest
Best regards
Kevin
=====
Reply by Kevin Karney on March 10, 2009 at 4:20pm
A year has passed
Is an update still planned..... ?
Best regards
Kevin Karney
=====
Reply by Jan Schenkel on March 16, 2009 at 7:17am
Hi Kevin,
Eight months does not make a year - at least not on this planet
Jokes aside, I want to assure you that the PDF Library has not been abandoned - in fact, this past week I prepped a new build for version 1.0 that fixes the 'underline' text style. Once the original reporter has confirmed that it does the trick, I'll make it available for everyone.
A little more to the point, development of version 1.1 is slowly inching forward. I managed to parse TrueType fonts but have yet to finish integrating this with the 1.1 alpha builds. Then it's on to the last couple of features I have slated for that version. In other words, you won't have to wait until 2010.
The plain truth is that my day-job pays for the bills and, as such, has first dibs on my time and energy. In the current economic climate, missing even the most absurd deadline there is not an option. Constantly juggling priorities isn't fun for anyone - but I'll do my best to wrap up development and start the beta test cycle as soon as all the pieces are in there and working reasonably stable.
Best regards,
Jan Schenkel
--
Quartam Reports & PDF Library for Revolution
www.quartam.com
=====
Reply by Rodney Tamblyn on December 10, 2009 at 7:28am
Hi Jan,
Just wondering if you could please give an update on your plans for PDF Library and release schedule.
Thank you
Regards,
Rodney
=====
Reply by Jan Schenkel on December 12, 2009 at 3:49pm
Hi All,
This is the part where I appear foot-in-mouth: Quartam PDF Library 1.1 will not come out in 2009 - I am currently snowed in by an unexpected update for multiple clients, thanks to changes in accounting for VAT-2010 (Value Added Tax, for non-EU-readers) that need to be ready for acceptance testing before the holidays.
Given that the cat is out of the bag on revEnterprise 4.1, I find myself in a situation that I was hoping to avoid: publicly unveiling plans before the new product strategy is completed. Yes, with revEnterprise 4.1 you will be able to print stacks to PDF files, regardless of platform (previously, this was only available on MacOSX) - so where does this leave Quartam PDF Library?
Let me make this crystal clear: the product will not be abandoned. Quite the opposite, this gives me the unique opportunity to focus on items that mere printing cannot provide: transformations, encryption, digital rights management, forms, embedded media, etc.
Obviously, one of my mistakes with this library has been that I got caught in the trap of 'big bang' upgrades: I have a pile of new functionality waiting to be released, and even more to start working on for future upgrades. It is said that software is always 90% finished but never more than 95% finished - my job now is to weed out the experimental items that I cannot complete short-term, and focus instead on the must-have enhancements.
Short-term plans:
- bring out version 1.0.1 at the start of January, abandoning the failed 1.0.0-gm-X versioning scheme (we're actually at gm-10), and rolling in some fixes and small changes
- shortly after that, I will finalise and announce the feature set for version 1.1, hopefully accompanied by the first feature-complete beta if possible (if not, I'll put out an alpha for you to play with until I have all features implemented)
When version 1.1 is done (I will say May now, but strive to surprise you in a positive manner) I will announce the shortlist of features for version 1.2 (current top two: forms and the ability to use existing PDF documents in the construction of new documents) as well as an expected ETA. It is indeed important to shorten development cycles and better manage expectations.
Naturally, I shouldn't leave Quartam Reports out of this explanation. In my opinion, RunRev adding PDF printing to revEnterprise will make my job easier on that front: I can deliver PDF printing of reports without having to figure out the platform-specific and advanced graphic effects rendering. Which means, in turn, that I can concentrate on rapidly improving that product with support for gradients and other graphics effects so that you can make your reports look even better.
Bear with me also as I get all ducks in a row for the other products that I have in the pipeline: the STOMP library and Java external that were previewed at RunRevLive'09. There's a lot to do in 2010 and I couldn't do it without your continued support.
If only there were more hours in a day...
Best regards,
Jan Schenkel
--
Quartam Reports & PDF Library for Revolution
www.quartam.com
=====
Reply by Kevin Karney on December 13, 2009 at 2:30pm
An early alpha version would be preferred to a late beta...
Best regards
kevin