[Sugar-devel] [PATCH Browse 0/2] Add support for Export as PDF
sascha-ml-reply-to-2011-3 at silbe.org
Sun Jun 26 05:29:47 EDT 2011
Excerpts from Christoph Derndorfer's message of Sat Jun 04 22:20:08 +0200 2011:
> (1) Are you suggesting that rather than being able to print directly from an
> activity users will have to export whatever they want to print to PDF, then
> launch a separate activity or go into the Journal to start the appropriate
> function and then print from there? If so this frankly speaking sounds like
> a lot of overhead to me.
Yes, that's the plan so far. We can reconsider the UI later if someone
presents a reasonable use case where the overhead really matters. There
are lots of different ways to reduce the overhead (without abandoning
the general approach) and which one is best depends on the details.
> (2) Assuming my assumption above is correct: Doesn't that mean that the
> text, image, whatever artifact a user wants to print will be stored twice in
> the Journal, once as the original (modifiable) object and once as the static
Yes, that is correct and fully intentional. You can continue editing the
original instance, but the PDF will retain an exact copy of the
> (3) You say that this approach "relieves activity authors from the need to
> provide print support in their activity", yet it seems to me that they will
> be required to add an "export to PDF for printing purposes" feature, right?
Yes, they need to add support for exporting PDFs. However they don't
need to implement all the other functionality that's required for
printing like preview, selecting pages, arranging pages (booklet mode),
zooming, etc. etc.. Take a look at the Adobe Acrobat Reader print
functionality to get a glimpse on the complexity of the problem.
While we could add this functionality to sugar-toolkit, activities would
either need to adjust their UI as the print functionality evolves or it
would be bolted on rather than integrated. The standard solution for
this on non-Sugar systems is to use pop-ups, but besides the usual
issues with modality their screen space is limited so much that a
preview dialog wouldn't be very useful on XOs (let alone PDAs like the
Olidata JumPC being rolled out in Uruguay).
Making this an activity solves the UI issues and also allows it to be
developed independently from the platform (in itself a very good reason
to go that route).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 500 bytes
Desc: not available
More information about the Sugar-devel