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

[Samuel Greenfeld]

On a slightly different note: what mechanism will be provided in Sugar
to set the page size, if there is none already?    What is going to be
the default page size (A4, Letter, etc.)?

And what printing margins are going to be used as the default, and
presumed to be supported by all printers?  When should an activity be
allowed to deviate from this?   Font embedding with PDFs also can be
another legal can of worms.

While PDFs could be resized and/or rotated by the print activity to
fit the available printable paper area, this tends to lead to a bit of
stretching in one axis or compressing another.  Unfortunately when a
PDF is generated, it is presumed that at least general information
about the eventual target output device(s) is known.

Care must also be taken not to have print settings unnecessarily
affect the view of a document on a computer screen/monitor.  At least
one commercial product out there was infamous for supposedly doing
this.



On Sun, Jun 26, 2011 at 5:29 AM, Sascha Silbe
<sascha-ml-reply-to-2011-3 at silbe.org> 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.
>
>
>> (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
>
>