[Sugar-devel] [PATCH Browse 0/2] Add support for Export as PDF
christoph.derndorfer at gmail.com
Sat Jun 4 16:20:08 EDT 2011
On Sun, May 29, 2011 at 4:04 PM, Sascha Silbe <silbe at activitycentral.com>wrote:
thanks a lot for your work on this front!
Requests for print functionality in Sugar have been voiced repeatedly,
> including during EduJam 2011. Adding support to Browse for exporting the
> currently loaded document as PDF is a major step in that direction since
> Browse can render (and thus export as PDF) a variety of file formats,
> including HTML, bitmap graphics (PNG, JPEG) and SVG.
> The Portable Document Format (PDF) is designed to preserve the layout of
> document and thus is poorly suited for applications like "offline" reading
> web pages (there is no re-flowing to suit the dimensions of the screen).
> these tasks there are better solutions like wwwoffle , Webified  or
> creating a derivative of the Help activity .
FWIW I don't think that PDF is ill-suited for offline reading. In fact
reading PDFs of Web sites has consistently been one of my main uses for my
XOs, particularly when I'm traveling and therefore offline. Yes, other
solutions might be better here but at least for me PDF gets the job done
> Direct print support has been deliberately omitted. Anything that gets
> exported from the learners system should be recorded and preserved in the
> Journal. Exporting PDFs from individual activities to the Journal and
> implementing print support in a single, specially designed activity that
> operates on the PDFs not only ensures that all exports are recorded in
> the exact form they left the computer, but also relieves activity authors
> from the need to provide print support in their activity. The user won't
> confused by multiple different ways to configure printing from within the
> various activities.
I am somewhat confused about what you're saying here but maybe I'm just
(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.
(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
(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?
It seems that any such functionality (regardless whether it's direct
printing or going through a PDF) would have to be somewhat customizable to
activities anyway. In Write for example it can be assumed that "print" means
the whole text yet for example what does "printing" in Tam Tam look like? A
screenshot of the current composition, an export of the actual tunes having
> Because PDF is a standard interchange format, this also enables more (and
> better!) ways of sharing documents (while preserving their exact form) than
> Sascha Silbe (2):
> Generalise GetSourceListener to SaveListener
> Add support for exporting ("printing") to PDF
> browser.py | 92
> webtoolbar.py | 10 ++++++
> 2 files changed, 93 insertions(+), 9 deletions(-)
>  http://www.gedanken.demon.co.uk/wwwoffle/
>  http://wiki.sugarlabs.org/go/Webified
>  http://activities.sugarlabs.org/en-US/sugar/addon/4051
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
e-mail: christoph at olpcnews.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel