[Sugar-devel] Print Support (journal vs activity)
[quoting tomeu] Hi all, my apologies for entering in this discussion so late, the soas and distributions deadlines played very badly with the gsoc schedule. If I understood correctly, the plan proposed in Vamsi's application implies that the conversion from the format in which activities write to a printable format like pdf would happen in the journal, I suppose through the use of cups and a set of filters. Is this right? I would like to know how we can expect that Sugar will be deployed with all the filters that the user will need as she installs more activities. Also would like to know if it has been considered to use instead the same approach that regular linux apps use. Thanks, [/quote] [quote=me]Tomeu ( from his sugar maintainer perspective) has expressed a potential disaster in the part-1 of my proposal, that is by using CUPS-Pdf we would be actually required a great load of filters which would be a nightmare for the maintainers. And also the issue to register each mime type with every install of a new activity, for which we would have to wait till a new sugar update. As an alternative he suggested I use gtkprint (for which again I have written a script and shown to tomeu), So anyway gtkprint makes use of a structure which is rendered to cairo objects and thus prints the screen as a pdf or prints to a printer ( a wrapper around cups) but the advantage is we dont utilisie that many filters again ( the implementation can be found in pyabiword ) But this would mean we do printing to device, and printing to pdf within activity only. For the moodle part, when in the print page, for the upload slots we limit it such that it can only upload pdfs OR what I had been thinking is, make py xmlrpc communicate with moodle's datastore, have a 'print to moodle' within the activity itself, and upload a maximum of three parallel live requests.. if 3 reached, disable the option The status updates of print requests and such can again be found in the moodle's print's user's page. The rest will be same as my proposal. [/quote] So talking to my mentor and silbe, I think I have sketched it like this, essentially each activity will be checked if it can print to pdf/ps or not, if not code in activity.py draws a cairo object (pdf) and makes an entry of it in journal. after which simple cups code can be written to print that pdf or send to moodle from journal. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vamsi Krishna Davuluri wrote: [quoting tomeu] I would like to know how we can expect that Sugar will be deployed with all the filters that the user will need as she installs more activities. Also would like to know if it has been considered to use instead the same approach that regular linux apps use. [/quote] Regular linux apps print through CUPS. To print something through CUPS, you submit a file to CUPS's print queue, for example using the lpr command. This file has to be in one of the formats CUPS supports. That list of formats is different on different machines. To see the list on your machine, look at /etc/mime/mime.convs. This shows the list of supported MIME types, and the command needed to process each one into postscript (which CUPS uses internally). As you can see from that list, all common image formats like jpeg, png, tiff, and bmp are supported. Text formats, like TXT and HTML are supported. Document formats like pdf and postscript are supported. Source code formats like c, sh, csh, and perl, are supported. Mine even has support for microsoft .doc! I think we should solve our printing problem by extending this list to a few more common formats. Add in python source and the Open Document Format, and we're pretty much done. There are very few Activities that generate documents that could be printed, but are not in one of these formats. Those Activities will have to gain the ability to export to one of the supported formats, just as they would on any standard linux desktop. The only remaining question is: who calls lpr?. In my view, the Activity should not have to call lpr, or otherwise initiate printing. Sugar's philosophy is to make things built in, as much as possible, so that Activity authors don't have to worry about these sorts of things. There's also a potential security problem if Activities can initiate printing without user interaction. Printing directly from the Journal seems like the logical way to handle this. If you are concerned about doing all this conversion on the local machine, then we can move all the filters onto the server, and have the print system transfer the raw file. Vamsi has argued against this idea, however, because he wants users to be able to convert things to PDF locally, without server access. So anyway gtkprint makes use of a structure which is rendered to cairo objects and thus prints the screen as a pdf or prints to a printer ( a wrapper around cups) but the advantage is we dont utilisie that many filters again ( the implementation can be found in pyabiword ) This is not very accurate. IIUC, gtkprint is just a shim connecting Cairo to CUPS. In this case, it's equivalent to drawing stuff in Cairo, and then exporting to PDF. In other words, it's a toolbox for writing PDF conversion filters. That means that the system still contains a great load of filters, only now the Activity authors have to maintain them. That doesn't seem like an improvement to me. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkntyggACgkQUJT6e6HFtqQfhgCdFOQctGzYpZo7/4bHxu66+NT7 W44AnAmcKXA8SD6pvhoumD3URBe2XisJ =x9qR -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
On Tue, Apr 21, 2009 at 15:28, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vamsi Krishna Davuluri wrote: [quoting tomeu] I would like to know how we can expect that Sugar will be deployed with all the filters that the user will need as she installs more activities. Also would like to know if it has been considered to use instead the same approach that regular linux apps use. [/quote] Regular linux apps print through CUPS. To print something through CUPS, you submit a file to CUPS's print queue, for example using the lpr command. This file has to be in one of the formats CUPS supports. That list of formats is different on different machines. To see the list on your machine, look at /etc/mime/mime.convs. This shows the list of supported MIME types, and the command needed to process each one into postscript (which CUPS uses internally). As you can see from that list, all common image formats like jpeg, png, tiff, and bmp are supported. Text formats, like TXT and HTML are supported. Document formats like pdf and postscript are supported. Source code formats like c, sh, csh, and perl, are supported. Mine even has support for microsoft .doc! I think we should solve our printing problem by extending this list to a few more common formats. Add in python source and the Open Document Format, and we're pretty much done. There are very few Activities that generate documents that could be printed, but are not in one of these formats. Those Activities will have to gain the ability to export to one of the supported formats, just as they would on any standard linux desktop. That's all fine, if the user sends a file to the printer spool, it gets converted to a printable format, then sent to print. That's how printing in unix works and there's no need to change it. The only remaining question is: who calls lpr?. In my view, the Activity should not have to call lpr, or otherwise initiate printing. Sugar's philosophy is to make things built in, as much as possible, so that Activity authors don't have to worry about these sorts of things. There's also a potential security problem if Activities can initiate printing without user interaction. Printing directly from the Journal seems like the logical way to handle this. The security concern makes sense to me, though I would like to hear from Eben what his thoughts are regarding user experience. What I think is important is that activities are given a chance to produce themselves the printable document, as they are the ones that can better do that. If you are concerned about doing all this conversion on the local machine, then we can move all the filters onto the server, and have the print system transfer the raw file. Vamsi has argued against this idea, however, because he wants users to be able to convert things to PDF locally, without server access. Well, I think we want both and we already have the needed infrastructure to do that. People deploying Sugar will chose which printing infrastructure can be installed in each machine and the server and Sugar will do whatever it can so stuff gets printed. I don't see a real need to choose one approach and not the other. So anyway gtkprint makes use of a structure which is rendered to cairo objects and thus prints the screen as a pdf or prints to a printer ( a wrapper around cups) but the advantage is we dont utilisie that many filters again ( the implementation can be found in pyabiword ) This is not very accurate. IIUC, gtkprint is just a shim connecting Cairo to CUPS. In this case, it's equivalent to drawing stuff in Cairo, and then exporting to PDF. In other words, it's a toolbox for writing PDF conversion filters. That means that the system still contains a great load of filters, only now the Activity authors have to maintain them. That doesn't seem like an improvement to me. Well, that's not very accurate ;) Gtkprint makes it a bit easier to reuse the cairo code you use to draw to screen to also print to paper. And we can expect that motivated activity authors will produce a better output that a generic filter converting some standard doc format. Again, what is very important to me is that activities are given a chance to produce the printable format, because they are probably the best that know how to print their stuff and because of code distribution: we cannot anticipate all the activities that will be installed on a system, we cannot anticipate which filters will be installed by the deployer/distributor and we already have a code distribution mechanism (bundles). To summarize, this is my proposal: - (py)gtk activities use gtkprint to produce a printable format, using an API that makes easy to use the same cairo drawing for the screen and paper. This doesn't mean that you print what you see on the screen, just that you are given the chance to reuse part of the cairo drawing you already
Re: [Sugar-devel] Print Support (journal vs activity)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: - (py)gtk activities use gtkprint. This means that they have an abstraction for printing to cups, lpr and to a file (ps or pdf). ... - implement a moodle module where users can upload whatever file they have in the journal. Depending on the printing filters installed on the server, there are more or less chances it can be converted to a printable format. How do these things go together? If all printing occurs by uploading files to Moodle, then why is it useful for Activities to talk to CUPS? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknt8ZMACgkQUJT6e6HFtqSolgCfblZVjfoUl4l0N7kk6zTyUxEG xlkAoKLTBSC3BpeUXTQIxDCa7gFMy9z5 =vtYA -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
On Tue, Apr 21, 2009 at 18:17, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: - (py)gtk activities use gtkprint. This means that they have an abstraction for printing to cups, lpr and to a file (ps or pdf). ... - implement a moodle module where users can upload whatever file they have in the journal. Depending on the printing filters installed on the server, there are more or less chances it can be converted to a printable format. How do these things go together? If all printing occurs by uploading files to Moodle, then why is it useful for Activities to talk to CUPS? Printing is not limited to uploading files to moodle, we provide both local and server printing and users will use whatever works in their environment. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: Printing is not limited to uploading files to moodle, we provide both local and server printing and users will use whatever works in their environment. I think this is too much for one Summer of Code project. That's why I have been recommending that we forget about local printing for now. Anyway, on a purely technical level I think we have reached agreement. (I do wonder whether the Moodle print queue should also support acting as a standard print server, so that standard desktops can print into the Moodle approval queue, but that's a detail.) - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknt9FQACgkQUJT6e6HFtqTjmwCfdM831aiEMbpRiJNQLX8Bf2FY OH8AniCGOPuqgY/GlR+V2io6+/NyiTnl =KI8s -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
It seems we can attack this in simple steps (sorry for the rehash of what has already be said): (1) a mechanism for printing Journal objects (anything of mime-type .pdf, txt, jpg, png, etc.) (2) an example of optional mechanisms for activities to drop additional printable objects into the Journal (3) exploration of printing directly from Sugar. -walter On Tue, Apr 21, 2009 at 12:29 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: Printing is not limited to uploading files to moodle, we provide both local and server printing and users will use whatever works in their environment. I think this is too much for one Summer of Code project. That's why I have been recommending that we forget about local printing for now. Anyway, on a purely technical level I think we have reached agreement. (I do wonder whether the Moodle print queue should also support acting as a standard print server, so that standard desktops can print into the Moodle approval queue, but that's a detail.) - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknt9FQACgkQUJT6e6HFtqTjmwCfdM831aiEMbpRiJNQLX8Bf2FY OH8AniCGOPuqgY/GlR+V2io6+/NyiTnl =KI8s -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
It's entirely unclear what this project has morphed to. Tomeu, what use is uploading arbitrary journal entries to Moodle? I thought creating pdf output in sugar and enabling uploading of the pdf to Moodle was the point of this project. That is useful in two ways. First, it is a path to assignment turn-in or printing either through Moodle or by other transports to a system configured to print pdfs. It also allows a student to review the printer-ready output to decide if it is worth getting hard copy. On Tue, Apr 21, 2009 at 9:36 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Apr 21, 2009 at 18:29, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: Printing is not limited to uploading files to moodle, we provide both local and server printing and users will use whatever works in their environment. I think this is too much for one Summer of Code project. That's why I have been recommending that we forget about local printing for now. I would actually be happy if we just implemented sending journal entries to the print queue and the moodle module. Print to pdf has several important use cases and I would like to see it implemented for 0.86 for at least Write and Browse, but I don't think it needs to be part of this GSoC. Anyway, on a purely technical level I think we have reached agreement. (I do wonder whether the Moodle print queue should also support acting as a standard print server, so that standard desktops can print into the Moodle approval queue, but that's a detail.) Yeah, I would prefer if we use simple file upload at first because it works already. There's lots of fun stuff to do in this area, but what gives most value to the user is quite straightforward. We should aim to leave the complicated stuff for the end, as extras, and focus on delivering what matters most first Regards, Tomeu - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknt9FQACgkQUJT6e6HFtqTjmwCfdM831aiEMbpRiJNQLX8Bf2FY OH8AniCGOPuqgY/GlR+V2io6+/NyiTnl =KI8s -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
On Tue, Apr 21, 2009 at 19:02, Carol Farlow Lerche c...@msbit.com wrote: It's entirely unclear what this project has morphed to. Tomeu, what use is uploading arbitrary journal entries to Moodle? Because the chances that the needed filter to convert that file to a printable format is in the server are bigger than being in every machine, for some deployments. I thought creating pdf output in sugar and enabling uploading of the pdf to Moodle was the point of this project. That is useful in two ways. First, it is a path to assignment turn-in or printing either through Moodle or by other transports to a system configured to print pdfs. It also allows a student to review the printer-ready output to decide if it is worth getting hard copy. Sure, I though I had made clear than printing to PDF in Sugar has important use cases. Regards, Tomeu On Tue, Apr 21, 2009 at 9:36 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Apr 21, 2009 at 18:29, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: Printing is not limited to uploading files to moodle, we provide both local and server printing and users will use whatever works in their environment. I think this is too much for one Summer of Code project. That's why I have been recommending that we forget about local printing for now. I would actually be happy if we just implemented sending journal entries to the print queue and the moodle module. Print to pdf has several important use cases and I would like to see it implemented for 0.86 for at least Write and Browse, but I don't think it needs to be part of this GSoC. Anyway, on a purely technical level I think we have reached agreement. (I do wonder whether the Moodle print queue should also support acting as a standard print server, so that standard desktops can print into the Moodle approval queue, but that's a detail.) Yeah, I would prefer if we use simple file upload at first because it works already. There's lots of fun stuff to do in this area, but what gives most value to the user is quite straightforward. We should aim to leave the complicated stuff for the end, as extras, and focus on delivering what matters most first Regards, Tomeu - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknt9FQACgkQUJT6e6HFtqTjmwCfdM831aiEMbpRiJNQLX8Bf2FY OH8AniCGOPuqgY/GlR+V2io6+/NyiTnl =KI8s -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
On Tue, Apr 21, 2009 at 05:56:59PM +0200, Tomeu Vizoso wrote: I think we should solve our printing problem by extending this list to a few more common formats. Add in python source and the Open Document Format, and we're pretty much done. There are very few Activities that generate documents that could be printed, but are not in one of these formats. Those Activities will have to gain the ability to export to one of the supported formats, just as they would on any standard linux desktop. That's all fine, if the user sends a file to the printer spool, it gets converted to a printable format, then sent to print. That's how printing in unix works and there's no need to change it. What I don't like about this option is that the _print_ _server_ decides how the printed out document actually looks like. Font family, font size, word wrapping, even what gets put on which page (due to page length and font size) and especially advanced formatting like syntax highlighting is all undefined. You will get different results depending on whether you use the XS at school, the printer with direct network interface (e.g. HP JetDirect) at home or a printer connected to a Windows machine (IIRC current Windows versions have IPP server support) at your friends. PDF and Postscript are bad enough: I've been responsible for administering the computer pools including the printers at our department for several years and saw how documents printed fine on one printer and came out rubbish on another. And that wasn't without explicit intention - PostScript is a full programming language and you can show entirely different things on screen and on the printed page (a good friend of mine - Caspar - once had a document which showed additional text on the printout about not being allowed to be printed). I was told by the head administrator of the archive of our university hospital that large digital archives have agreed to use some ISO standard that's a subset of PDF, called something like PDF/A. What I think is important is that activities are given a chance to produce themselves the printable document, as they are the ones that can better do that. +1. It just needs to go through Journal, like downloads from Browse do. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
On Tue, Apr 21, 2009 at 19:20, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Tue, Apr 21, 2009 at 05:56:59PM +0200, Tomeu Vizoso wrote: I think we should solve our printing problem by extending this list to a few more common formats. Add in python source and the Open Document Format, and we're pretty much done. There are very few Activities that generate documents that could be printed, but are not in one of these formats. Those Activities will have to gain the ability to export to one of the supported formats, just as they would on any standard linux desktop. That's all fine, if the user sends a file to the printer spool, it gets converted to a printable format, then sent to print. That's how printing in unix works and there's no need to change it. What I don't like about this option is that the _print_ _server_ decides how the printed out document actually looks like. That's fine, if the user wishes to control that, then does the conversion to PDF locally and sends the PDF. Regards, Tomeu Font family, font size, word wrapping, even what gets put on which page (due to page length and font size) and especially advanced formatting like syntax highlighting is all undefined. You will get different results depending on whether you use the XS at school, the printer with direct network interface (e.g. HP JetDirect) at home or a printer connected to a Windows machine (IIRC current Windows versions have IPP server support) at your friends. PDF and Postscript are bad enough: I've been responsible for administering the computer pools including the printers at our department for several years and saw how documents printed fine on one printer and came out rubbish on another. And that wasn't without explicit intention - PostScript is a full programming language and you can show entirely different things on screen and on the printed page (a good friend of mine - Caspar - once had a document which showed additional text on the printout about not being allowed to be printed). I was told by the head administrator of the archive of our university hospital that large digital archives have agreed to use some ISO standard that's a subset of PDF, called something like PDF/A. What I think is important is that activities are given a chance to produce themselves the printable document, as they are the ones that can better do that. +1. It just needs to go through Journal, like downloads from Browse do. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJJ7gBLAAoJELpz82VMF3DaHjEH/1gYJB2sPRTJXcn9UizxkLCb ZqCTPG8z2a2tTZKf7Qp+UgVHbcEB3Rqp1/hw7fSebLYwA/+NeZPmaM3RNWkVkUIu xxDU//FBUkXl8NzAVcGdkTa1jiqOx2uvpxyWWqaANyPJFyKDXuyHQtQN+iMRSHN5 FB2et+pmUsVDMgAGixD8oM3EsUTZWTjYBt6q35ArGG0lXx/lVD6ka6vYiHxAfy0o jk7mt365yDMCJO9masrt1QCjNZm81HD6BIOkevXqkyE0Vck7m/iDXrGrInRiygsv kG6jBKB7evamQLKRCw5TzhaEGK0ansQlH0l7gEihOHX4tMy7IDsDaGO41wQ81rY= =FgFk -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
OK, we just had an animated conversation on IRC in which almost nothing was generally agreed-on. Here's my refined proposal based on that conversation. Print preview option in journal Uses cups filters to convert to PDF Set of cups filters available is distribution dependent. An officially print enabled distribution would have a certain limited set of filters installed (the obvious ones). Filters outside this set would be mildly discouraged to avoid inconsistent behaviour. filters would NOT be part of sugar-platform, to leave maximum flexibility for deployments if you had anything but the exact, limited set of print-enabled filters, printing behaviour would be officially undesigned and unsupported but nevertheless probably sane enforcement would be social, not digital the PDF thus created would have special print-me tag To add to print queue, or any other queue management, you'd use Browse there are several options for streamlining the workflow. the moodle form could have metadata in the tag for the upload control to tell sugar to please filter for print-me tag this means making sugar understand this kind of metadata - independently useful you could make a print activity, a spin of browse, which handles PDFs it would open the PDF using a pdf-viewer plugin it would have an enqueue menu item choosing this menu item would go to moodle and put the pdf in the upload tag (using some greasemonkey-like trick) You could modify sugar to know when to use Print instead of Read by default, based on print-me tag using something in activity.info this functionality would be independently useful Activities which wanted printing but did not naturally produce a format within our basic filter list, could have a print preview menu item and use gtkprint to export to pdfs with a print-me tag gtkprint would be a dependency of sugar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
Ooops, I forgot. In my proposal, local printing would be done by a separate activity which handled only PDFs. Many deployments would never install this separate activity. On Tue, Apr 21, 2009 at 11:58 AM, Jameson Quinn jameson.qu...@gmail.comwrote: OK, we just had an animated conversation on IRC in which almost nothing was generally agreed-on. Here's my refined proposal based on that conversation. Print preview option in journal Uses cups filters to convert to PDF Set of cups filters available is distribution dependent. An officially print enabled distribution would have a certain limited set of filters installed (the obvious ones). Filters outside this set would be mildly discouraged to avoid inconsistent behaviour. filters would NOT be part of sugar-platform, to leave maximum flexibility for deployments if you had anything but the exact, limited set of print-enabled filters, printing behaviour would be officially undesigned and unsupported but nevertheless probably sane enforcement would be social, not digital the PDF thus created would have special print-me tag To add to print queue, or any other queue management, you'd use Browse there are several options for streamlining the workflow. the moodle form could have metadata in the tag for the upload control to tell sugar to please filter for print-me tag this means making sugar understand this kind of metadata - independently useful you could make a print activity, a spin of browse, which handles PDFs it would open the PDF using a pdf-viewer plugin it would have an enqueue menu item choosing this menu item would go to moodle and put the pdf in the upload tag (using some greasemonkey-like trick) You could modify sugar to know when to use Print instead of Read by default, based on print-me tag using something in activity.info this functionality would be independently useful Activities which wanted printing but did not naturally produce a format within our basic filter list, could have a print preview menu item and use gtkprint to export to pdfs with a print-me tag gtkprint would be a dependency of sugar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
Vamsi, for your reference, here is the discussion on IRC in which nobody agreed on anything, but we all wanted to take over design of your project. We're just being enthusiastic, and there's some significant degree of bike-shedding http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Trivialityhere. In the end, you are the engineer, and aa is the manager; anything you design that's OK with him is fine. Your job right now is to listen to and participate in the discussion, but set a strict time limit (a few days, I'd say). When the time is up, you write up your design, get aa's OK, and then ignore us from then on :). (the IRC discussion below is tangled and confusing. At the end we agree to do it on this mailing list, so if you want to skip reading below, that's fine. I'm just posting it in case you want to see the sausage being made.) [11:08] tomeu homunq: have some problems following your last email about printing [11:09] tomeu what means default action from journal for print-me pdfs? [11:09] -- satellitFbe-74c6 has joined this channel (n= u...@208-100-132-172.bendbroadband.com). [11:12] homunq tomeu: there would be some metadata besides mime-type, something like sub-type [11:12] homunq all pdfs created for printing would have a specific sup-type. This would make them print-me pdfs. [11:12] tomeu ok, what would that metadata be? which component would use that new property? [11:13] homunq sugar, when choosing which activity to use as a default, when several activities handle a given mime-type, would give preference to activities which have the same sub-type metadata. [11:14] homunq does that make sense? [11:14] tomeu why do activities other than Read need to open those pdfs? [11:14] homunq so both print and read would handle pdfs. [11:15] homunq print would be, within GSoC scope, an activity with no UI - just enqueue and terminate. [11:15] -- eben has left this server (Read error: 110 (Connection timed out)). [11:15] homunq eben, we hardly knew ye. [11:16] homunq is that clear? And should I make the same clarifications on ML? [11:16] tomeu homunq: why do we need an activity with no UI? [11:17] tomeu homunq: enqueue should be pretty easy to do in the journal by using gtkprint [11:17] homunq um, because that's the work flow? [11:17] tomeu just like we don't have an activity for copying files from a usb stick to the journal [11:17] tomeu homunq: which workflow? [11:17] homunq I mean, there would be several versions/updates of the activity possible. [11:18] tomeu by sending a file to the print queue is quite trivial in pygtk [11:18] homunq the no-UI version is just alpha, for GSoC. [11:18] tomeu s/by/but [11:18] homunq what print queue? [11:18] tomeu and about the preview UI, why not just use Read? [11:18] homunq the moodle queue on the XS? [11:18] tomeu homunq: cups, lpr, whatever [11:18] tomeu the moodle queue, I think it's enough with file uploading in browse for now [11:19] tomeu that gives us authentication and is already done [11:19] homunq OK, so print activity is a spin of browse. [11:19] tomeu printing from the journal means for me to just submit a file to the local printing queue [11:19] homunq the local printing queue is meaningless. [11:20] tomeu homunq: well, it's the same thing you have in windows when you send documents to print [11:20] tomeu in most cases won't make sense, but it's stuff that it's already done [11:20] homunq yes but the moodle queue is the whole point of this GSoC [11:20] tomeu and will be important for a teacher printing from sugar to an attached printer, for example [11:21] tomeu homunq: ok, I don't think it's needed to implement local printing in this gsoc [11:21] -- J5 has joined this channel (n= quint...@c-24-91-155-241.hsd1.ma.comcast.net). [11:21] homunq but we don't want to give every kid UI that only the teacher will use. Much confusion results. [11:21] tomeu so for uploading the file to moodle, can we just let the user use browse like would do for any other moodle-related stuff? [11:21] tomeu homunq: sugar will be used out from classrooms [11:22] tomeu homunq: want it or not, we are being asked to be able to directly print from sugar, and it's quite cheap to implement [11:22] tomeu homunq: but I would prefer if the gsoc project focused on moodle [11:22] tomeu don't worry about this now [11:22] homunq OK. So the workflow is: print to pdf. Resulting pdf has some print-me tag. Browse to upload - can search for print-me tag for easier upload. [11:23] homunq print to pdf is from inside journal, to journal. [11:24] tomeu not sure I understand the importance of that print-me tag [11:25] *** nubae1 is now known as Nubae. [11:25] homunq future enhancement is to do a spin of browse that handles PDF, and has a print-me menu item which will pre-fill the upload form with the given pdf. [11:25] tomeu but on the other hand, I think it may be good to start tagging entries automatically as we do stuff with entries, if it doesn't become cumbersome for the user [11:25] aa me neither...
Re: [Sugar-devel] Print Support (journal vs activity)
On Tuesday 21 April 2009 14:16:36 Tomeu Vizoso wrote: On Tue, Apr 21, 2009 at 19:02, Carol Farlow Lerche c...@msbit.com wrote: It's entirely unclear what this project has morphed to. Tomeu, what use is uploading arbitrary journal entries to Moodle? Because the chances that the needed filter to convert that file to a printable format is in the server are bigger than being in every machine, for some deployments. I thought creating pdf output in sugar and enabling uploading of the pdf to Moodle was the point of this project. That is useful in two ways. First, it is a path to assignment turn-in or printing either through Moodle or by other transports to a system configured to print pdfs. It also allows a student to review the printer-ready output to decide if it is worth getting hard copy. Sure, I though I had made clear than printing to PDF in Sugar has important use cases. Regards, Tomeu My idea for dealing with the headache of filters is assuming only pdf/ps is printable, and having the Journal display a Print button if and only if the mimetype is pdf or ps. This way we can then make the decision of sending it to moodle via xml-rpc, a local cups queue, or a remote cups server using lpr. Activities that can't output to pdf/ps will be provided with gtkprint facilities and a pdf journal entry will be generated after they draw their output. Vamsi has already hacked pdf output into Write, so that's one big activity we will have covered. For the security issues, activities will only generate a journal pdf entry, which would be displayed using show_object_in_journal or somesuch (just like Chat currently handles opnening URLs). The user will then have the ability to immediately review the printable output and/or send it to the preferred queue. This architecture follows some basic principles: 1) Paper/Ink is expensive, we need a way to easily and reliably review what's going to be printed. Requiring people to load up Browse, navigate inside Moodle, and download a PDF file for review, is not exactly user-friendly. 2) We don't need to specify a set of required filters...yet, we can easily expand this to well, HTML, JPG and PNG are probably going to be supported by every CUPS out there, so admit those as well, but I think 1) is priority here. 3) Following up on 2), the journal mechanism is orthogonal to what we end up sending to Moodle. Ben and Tomeu have sort of agreed on sending the raw journal entries to Moodle, so we can use all the CUPS filters on the server, this conflicts with 1) in my view, but it has its advantages. On Tue, Apr 21, 2009 at 9:36 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Apr 21, 2009 at 18:29, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: Printing is not limited to uploading files to moodle, we provide both local and server printing and users will use whatever works in their environment. I think this is too much for one Summer of Code project. That's why I have been recommending that we forget about local printing for now. I would actually be happy if we just implemented sending journal entries to the print queue and the moodle module. Print to pdf has several important use cases and I would like to see it implemented for 0.86 for at least Write and Browse, but I don't think it needs to be part of this GSoC. Anyway, on a purely technical level I think we have reached agreement. (I do wonder whether the Moodle print queue should also support acting as a standard print server, so that standard desktops can print into the Moodle approval queue, but that's a detail.) Yeah, I would prefer if we use simple file upload at first because it works already. There's lots of fun stuff to do in this area, but what gives most value to the user is quite straightforward. We should aim to leave the complicated stuff for the end, as extras, and focus on delivering what matters most first Regards, Tomeu - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknt9FQACgkQUJT6e6HFtqTjmwCfdM831aiEMbpRiJNQLX8Bf2FY OH8AniCGOPuqgY/GlR+V2io6+/NyiTnl =KI8s -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Andrés signature.asc Description: This is a digitally signed message part. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org
