[Sugar-devel] [PATCH Browse 0/2] Add support for Export as PDF

[Gary Martin]

On 26 Jun 2011, at 10:29, Sascha Silbe wrote:

> 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
>> PDF?
> 
> Yes, that is correct and fully intentional. You can continue editing the
> original instance, but the PDF will retain an exact copy of the
> print-out.

Also worth mentioning that a Print Activity could support some of the more common mime objects that might need printing (jpg, png, plain text, etc), avoiding the need for duplication as a pdf. You'd just use the Journal or detail view to Resume with --> Print Activity (we would likely not want the Print Activity to take ownership of the object).

Regards,
--Gary

>> (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).
> 
> Sascha
> 
> -- 
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel