Re: [Sugar-devel] Print Support proposal (need input) Beta
I can't speak for the classroom, but in the house I have two kids very active with their Mac computers and often wishing to print. I think printing is an area where lots of little things can go wrong which need grownups to sort out. I have a single printer connected to a computer on the main floor. The kids started out (at ages 9 and 11, two years ago) by trying to print everything, printing 80-page documents they downloaded, making minor changes to get something to fit and printing each one, not knowing what to do with the pile of badly printed paper, getting frustrated when no-ink message and I wasn't around to pop in a new cartridge. When I disapproved of printing a very long document, they got wise and paused the printer queue, sent their print job to the queue, went downstairs to see if I was around or not, then unpaused the queue. So I taught them to *always* print to PDF, check how it came out, try again until it looked fine, *then* print the PDF. And if the printer was offline, instead of a crisis where they were worried about their stuff, they immediately had options: wait until I get home, e-mail it to a friend with a working printer, mail it right to the teacher. They learned to keep their PDFs in a directory and liked being able to look at or reprint an older document without looking for the source document, which moreover they had sometimes updated and wrecked the page layout and in this case they were able to fall back to the printable PDF. In particular, they appreciate that printing should be thought about twice before being done. What I like about the scenario of classroom kids gaining permission to print, hooking up directly, and then printing with the teacher is that it underlines the expense (including environmental) involved and boosts the probability that the teacher will be able to fix the little problems (paper jam, ink) which kids have trouble solving without making it worse (e.g. pulling out jammed paper and stripping gears). I, too, think the priority should be classroom needs, not adult G1G1 users. thanks Sean P.S. way back in the days of Windows v3.1, the CLI copy command (also available from the GUI file manager where I usually used it) was able to print to parallel port lptx devices, e.g.: copy /b mydoc.prn lpt1 this was a function I used all the time, very useful as it worked even if the parallel port in question was captured or redirected (i.e. with Netware and redirected to a print queue). This disappeared from Windows 95 onwards and I have missed it ever since. On Fri, Mar 20, 2009 at 11:46 AM, Albert Cahalan acaha...@gmail.com wrote: 2009/3/19 Benjamin M. Schwartz bmsch...@fas.harvard.edu: Specifically, there are at least 3 different use cases you may choose to support: 1. USB printer connected directly to the Sugar machine. This is likely, even in a classroom environment. The printer may sit next to the teacher, who gives approval to connect. Students show their work to the teacher, get approval, plug in the cable, and print. Plugging in the cable might prompt the user for printing, either to select things or to confirm jobs that are already queued. 2. Networked printer, no server. Sugar prints directly over the network. This is somewhat likely. It's very simple. You can get a tiny box that will convert any printer into a network printer. Networked printers tend to be reliable and cheap when you don't ignore server costs. 3. All printing passes through a server. a. networked printer with restricted access b. USB printer connected directly the server and also 1. the server may print every submission immediately 2. apply automatic quotas, or 3. require manual approval This is getting complicated. Real IT support will be needed. The server, including all the extra cabling, is a failure point. Usability drops; now one must boot the server and muck with the permissions. I think you should focus on #3 and ignore #1 and #2. I say this because #3 does not require CUPS, or _any_ printing stuff, in Sugar. You don't even need to include the print to PDF functionality in Sugar. All you need to do is send the file you want to print to the server, over the network. The server (running CUPS) can take the file (png for Paint, jpg for Record, odt for Write) and convert it to postscript for printing. Lots of useful software prints roughly like so: fp=fopen(/tmp/4wiP9r.ps,w); fwrite(printout,1,nbytes,fp); fclose(fp); system(lpr /tmp/4wiP9r.ps); Sometimes PDF is used instead of PS. Sometimes popen() is used instead of a tmp file. Sometimes lp is run instead of lpr. Sometimes bare system calls (open,write,close,pipe,execve) are used instead of stdio. For example, Tux Paint normally sends PS into popen(lpr). CUPS is among the many ways to support this. It's certainly not the only game in town. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org
Re: [Sugar-devel] Print Support proposal (need input) Beta
Print queue management and quotas are key to this feature being usable in a classroom/school environment. Consumables are very expensive and kids love to hit print, often without thinking. So providing a way to place print jobs in a hold for review status is very important, IMHO, as well as providing a way to look through the queue releasing only the jobs you really want to print. 2009/3/19 Vamsi Krishna Davuluri vamsi.davul...@gmail.com Hello! So here is a refined and less abstract approach for the Print Idea. (input credit Luke, Ben, Tomeu) Initial problem: where do we get the cups daemon/server from, and how do we have it working on python since its written in c? solution: The cups daemon would only need to be running on the core distro (add it as a dependency), and we have the amazing pycups bindings which wrap it up, so we can use in our configuration program and other apis which we will discuss. Now, that we have CUPS ready, lets step into implementing it problem 2: Interacting with the CUPS daemon to actually configure the printer solution: Debian has a python version of print-system-configure UI, hacking into the code will yield a decent template for fedora. Which can then be tailored to fit the sugar guidelines. problem 3: Who does the actual printing of the files?! solution: well, again there's these amazing pygtk print modules that take care of it. They make the CUPS API a backend, and work as a decent printing API, they again access the print-system-configure UI(or diving more deeply, the files postscript files (PPD) ) ( I have written a sample printing program demonstrating it on fedora) NOW LETS SUGARIZE THEM! (oh sweet sugar) problem4: We have everything ready but where do we put our print-system-conifguration? solution: we strip the debian (python based) UI, and dress it up with our nice sparkling UIs (the sugar design apis ) and put it in the control panel Here's where I propose an extra credit : Make the configuration An Interactive Wizard, (someone add groovy animations later on, or its on the end list on me) , as we will have to provide a default printer configuration at least once, despite cups having the ability to automatically select the printer. problem5: Okay, okay most of the job is done. Now where do we print from? answer: We print from that one place ofcourse, The Journal! (after all its he uncrowned king bad joke) As it is it is against the bitfrost system for a program to both access the network and the journal at the same time - secuirty constrictions. and also as to see that activity writers dont have to struggle with the print code, we can just see that the print requests are rendered into nice pdfs (CUPS again, we can print to pdfs) with the click of a magical button,store them at a known location and send those 'hit coordinates' and if any metadata by the IPC, and queue them up on journal for print. As an ACK send back a notification to the activity stating, You have a print job waiting, print it with default settings? or go to journal to edit settings Remember how i said pygtk can interact with the CUPS settings, well we will implement the relatively important ones in the journal as an option. Extra credit: I've been thinking about this make the school server take in network print requests (feasible/required or not? input please) Obscure stuff: CUPS server, Quota management, and permissions, CUPS server is a background process (hence daemon) which loopsback over the listening ports and ips. CUPS already benefits from a standard print quota management, the secrets of the implementation are in our debian configuration UI. permissions: ( I need input here) print permissions should be of any matter only if its a network assignment as far as i know. So what's the end result:: A nice interactive printer configuration wizard! Minimal work for the activity author! (an addition of 3 modules to print to pdf, but it will be of great value, as the user can present his work in as a pdf within the activity) Journal acting as print dock! pdf printing! And everything sugarized P.S. My actual application will be formal, please dont kill me :P Input Input Input please! Thank You Vamsi Krishna Davuluri ___ 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 proposal (need input) Beta
Carol, thanks for replying! Much appreciated! So in a classroom environment, can I assume the classroom server will be acting as the server? The thing is I never got proper input on what I branded obscure. Yes, I agree, if its a classroom environment I'll definitely add permission access and queuing management. Permissions I'd grant as follow: Only the requester and the print server owner can remove the requesters job from the queue, otherwise there is no way to stop the job. Implementation to check match IP address should do the trick, a read in the configuration file, and the originating signal. On Thu, Mar 19, 2009 at 10:00 PM, Carol Farlow Lerche c...@msbit.comwrote: Print queue management and quotas are key to this feature being usable in a classroom/school environment. Consumables are very expensive and kids love to hit print, often without thinking. So providing a way to place print jobs in a hold for review status is very important, IMHO, as well as providing a way to look through the queue releasing only the jobs you really want to print. 2009/3/19 Vamsi Krishna Davuluri vamsi.davul...@gmail.com Hello! So here is a refined and less abstract approach for the Print Idea. (input credit Luke, Ben, Tomeu) Initial problem: where do we get the cups daemon/server from, and how do we have it working on python since its written in c? solution: The cups daemon would only need to be running on the core distro (add it as a dependency), and we have the amazing pycups bindings which wrap it up, so we can use in our configuration program and other apis which we will discuss. Now, that we have CUPS ready, lets step into implementing it problem 2: Interacting with the CUPS daemon to actually configure the printer solution: Debian has a python version of print-system-configure UI, hacking into the code will yield a decent template for fedora. Which can then be tailored to fit the sugar guidelines. problem 3: Who does the actual printing of the files?! solution: well, again there's these amazing pygtk print modules that take care of it. They make the CUPS API a backend, and work as a decent printing API, they again access the print-system-configure UI(or diving more deeply, the files postscript files (PPD) ) ( I have written a sample printing program demonstrating it on fedora) NOW LETS SUGARIZE THEM! (oh sweet sugar) problem4: We have everything ready but where do we put our print-system-conifguration? solution: we strip the debian (python based) UI, and dress it up with our nice sparkling UIs (the sugar design apis ) and put it in the control panel Here's where I propose an extra credit : Make the configuration An Interactive Wizard, (someone add groovy animations later on, or its on the end list on me) , as we will have to provide a default printer configuration at least once, despite cups having the ability to automatically select the printer. problem5: Okay, okay most of the job is done. Now where do we print from? answer: We print from that one place ofcourse, The Journal! (after all its he uncrowned king bad joke) As it is it is against the bitfrost system for a program to both access the network and the journal at the same time - secuirty constrictions. and also as to see that activity writers dont have to struggle with the print code, we can just see that the print requests are rendered into nice pdfs (CUPS again, we can print to pdfs) with the click of a magical button,store them at a known location and send those 'hit coordinates' and if any metadata by the IPC, and queue them up on journal for print. As an ACK send back a notification to the activity stating, You have a print job waiting, print it with default settings? or go to journal to edit settings Remember how i said pygtk can interact with the CUPS settings, well we will implement the relatively important ones in the journal as an option. Extra credit: I've been thinking about this make the school server take in network print requests (feasible/required or not? input please) Obscure stuff: CUPS server, Quota management, and permissions, CUPS server is a background process (hence daemon) which loopsback over the listening ports and ips. CUPS already benefits from a standard print quota management, the secrets of the implementation are in our debian configuration UI. permissions: ( I need input here) print permissions should be of any matter only if its a network assignment as far as i know. So what's the end result:: A nice interactive printer configuration wizard! Minimal work for the activity author! (an addition of 3 modules to print to pdf, but it will be of great value, as the user can present his work in as a pdf within the activity) Journal acting as print dock! pdf printing! And everything sugarized P.S. My actual application will be formal, please dont kill me :P Input Input Input please!
Re: [Sugar-devel] Print Support proposal (need input) Beta
class room/school server as the print server* On Thu, Mar 19, 2009 at 10:11 PM, Vamsi Krishna Davuluri vamsi.davul...@gmail.com wrote: Carol, thanks for replying! Much appreciated! So in a classroom environment, can I assume the classroom server will be acting as the server? The thing is I never got proper input on what I branded obscure. Yes, I agree, if its a classroom environment I'll definitely add permission access and queuing management. Permissions I'd grant as follow: Only the requester and the print server owner can remove the requesters job from the queue, otherwise there is no way to stop the job. Implementation to check match IP address should do the trick, a read in the configuration file, and the originating signal. On Thu, Mar 19, 2009 at 10:00 PM, Carol Farlow Lerche c...@msbit.comwrote: Print queue management and quotas are key to this feature being usable in a classroom/school environment. Consumables are very expensive and kids love to hit print, often without thinking. So providing a way to place print jobs in a hold for review status is very important, IMHO, as well as providing a way to look through the queue releasing only the jobs you really want to print. 2009/3/19 Vamsi Krishna Davuluri vamsi.davul...@gmail.com Hello! So here is a refined and less abstract approach for the Print Idea. (input credit Luke, Ben, Tomeu) Initial problem: where do we get the cups daemon/server from, and how do we have it working on python since its written in c? solution: The cups daemon would only need to be running on the core distro (add it as a dependency), and we have the amazing pycups bindings which wrap it up, so we can use in our configuration program and other apis which we will discuss. Now, that we have CUPS ready, lets step into implementing it problem 2: Interacting with the CUPS daemon to actually configure the printer solution: Debian has a python version of print-system-configure UI, hacking into the code will yield a decent template for fedora. Which can then be tailored to fit the sugar guidelines. problem 3: Who does the actual printing of the files?! solution: well, again there's these amazing pygtk print modules that take care of it. They make the CUPS API a backend, and work as a decent printing API, they again access the print-system-configure UI(or diving more deeply, the files postscript files (PPD) ) ( I have written a sample printing program demonstrating it on fedora) NOW LETS SUGARIZE THEM! (oh sweet sugar) problem4: We have everything ready but where do we put our print-system-conifguration? solution: we strip the debian (python based) UI, and dress it up with our nice sparkling UIs (the sugar design apis ) and put it in the control panel Here's where I propose an extra credit : Make the configuration An Interactive Wizard, (someone add groovy animations later on, or its on the end list on me) , as we will have to provide a default printer configuration at least once, despite cups having the ability to automatically select the printer. problem5: Okay, okay most of the job is done. Now where do we print from? answer: We print from that one place ofcourse, The Journal! (after all its he uncrowned king bad joke) As it is it is against the bitfrost system for a program to both access the network and the journal at the same time - secuirty constrictions. and also as to see that activity writers dont have to struggle with the print code, we can just see that the print requests are rendered into nice pdfs (CUPS again, we can print to pdfs) with the click of a magical button,store them at a known location and send those 'hit coordinates' and if any metadata by the IPC, and queue them up on journal for print. As an ACK send back a notification to the activity stating, You have a print job waiting, print it with default settings? or go to journal to edit settings Remember how i said pygtk can interact with the CUPS settings, well we will implement the relatively important ones in the journal as an option. Extra credit: I've been thinking about this make the school server take in network print requests (feasible/required or not? input please) Obscure stuff: CUPS server, Quota management, and permissions, CUPS server is a background process (hence daemon) which loopsback over the listening ports and ips. CUPS already benefits from a standard print quota management, the secrets of the implementation are in our debian configuration UI. permissions: ( I need input here) print permissions should be of any matter only if its a network assignment as far as i know. So what's the end result:: A nice interactive printer configuration wizard! Minimal work for the activity author! (an addition of 3 modules to print to pdf, but it will be of great value, as the user can present his work in as a pdf within the activity) Journal acting as
Re: [Sugar-devel] Print Support proposal (need input) Beta
2009/3/19 Carol Farlow Lerche c...@msbit.com: A problem with the desktop-oriented printer support in Unix and in Windows is that it has the underlying assumption that the person at the desktop should be in unfettered control of the ability to print (with lip service paid to an overall page quota). Where this breaks down for children is that . kids love tangible output, so unless someone does something about it, they will print everything. . in a school the printer may be somewhere else than in the classroom, and kids aren't allowed to roam the building picking up their output. So even more than printer users in an office environment, they have no clue as to why things don't show up as printed, or why the print queue is long. (Could be a printer jam. Could be a graphics-intensive prior job, or their own job being graphics-intensive, could be an unwitting print of a 30 page job on a slow printer, etc., etc.) Just as in the hit the launch button again phenomenon when activity launching is slow on the XO, this leads to printing the same document again and again. I'd like to show you the scars from the arrows in my back after spending a day a week in elementary school classrooms over a period of several years, but it would scare the children. So here is a scenario that I think would be better, especially in an environment such as a third world school with few printers and scarcity of paper/toner/ink. Vamsi's default pdf printer is great...no consumables, no remote print server, nice way to preserve the visual effect of a piece of work for posterity. But for printing real output, I think a more draconian control system is needed. One possibility: submit pdf files to a Moodle-mediated turn it in queue. This ensures that an artifact has been produced that the child can review and is motivated to review before giving it to the teacher to decide if it warrants printing. The teacher can then browse the turned in work, printing those examples s/he thinks warrant the expense. Should it be possible to configure a normal CUPS printer queue where kids could just print it? Yes, there are probably circumstances where this is appropriate. But even where kids make the decision about what to print, I think having some kind of per-document filter, such as has this document already been printed in the last n hours?, is this document longer than x pages?, has this child submitted more than y pages in the last time period is crucial. And so it would be good to build that into the journal print interface. I don't think the ordinary unix print quota mechanism does this, but I admit I haven't looked at it in detail recently. I wonder if printer control could be managed in a social way rather than a technical one? Say, if a child wants something printed, they use Journal File Transfer to send it to their teacher, who prints it for them if they deem it appropriate. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
2009/3/19 Vamsi Krishna Davuluri vamsi.davul...@gmail.com one question, the school server will be running on a normal distro, or sugar? Fedora CLI, see http://wiki.laptop.org/go/School_server 2009/3/19 Carol Farlow Lerche c...@msbit.com I disagree that print-to-pdf should be omitted. I think print to pdf is important for submitting work in a portable, frozen in amber way. The printer interface may be on a platform that does not have support for all the file formats of the native XO activities. Someone may want to print an artifact at a later time when activity file incompatibilities intrude. I agree. In addition, we may later decide to implement signatures on these documents. -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vamsi Krishna Davuluri wrote: But as tomeu had pointed out, what of the schools without servers? In that case printing would have a need to be done from the laptops themselves. Yes. There are lots of potential use cases that you might support, but you will not be able to support them all. I am suggesting that you approach this as a critical path problem. Do the absolute minimum amount of work necessary to achieve useful functionality in some situations, and then grow it from there. And personally I would definitely prefer a client-server approach as it simplifies many things. But shouldn't the print-to-pdf be a good addition? In my opinion that would at least give the kids something through which they can display their presentations to the real world. I agree the ability to convert things to PDF would be nice to have. I even proposed it as a feature of the Journal in June: http://lists.sugarlabs.org/archive/sugar-devel/2008-June/006598.html What I am saying here is: conversion to PDF within Sugar is not on the critical path to working print support. one question, the school server will be running on a normal distro, or sugar? The school server is running a normal distribution, probably headless. I believe pdf printing should be present on the laptops at least, so I will push it as an end derivable. Well, that's fine. I just want to warn you against putting too many things into one Summer of Code proposal. Remember: most Summer of Code projects fail, because the project is too big and the code never reaches sufficient quality to be merged into the main codebase. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknCkFoACgkQUJT6e6HFtqQQEACcCmit2diezRw7Jsa3KW9UVuGo /msAniY1boOs/7GaXuDBnoZdjQ+7QKGQ =4kja -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: I have to agree that a print to pdf function could be useful, though, especially since it means that every activity can create output that can be transferred elsewhere (via email, USB drive, etc.) for printing. This provides a method, albeit indirect, for G1G1 users to print from various activities whose file formats are only understood by a Sugar activity. No, it doesn't. What we are discussing here is building PDF conversion functionality directly into Glucose. That means that the PDF renderer will support a fixed set of common file formats, corresponding to the output of a few popular Activities. At the moment, I am not aware of any Activity that produces printable data in a nonstandard format. Write produces Open Document Text. Record produces JPEG. Paint produces PNG. Therefore, these are the formats that the PDF renderer will support. All of these files can already be opened by the corresponding standard software on any of the major desktops. There is no significant gain in compatibility in regard to printing. It also means that there would always be a way to send the artifact of some activity to another XO, without having to send the raw file (which would require the other XO to have that activity, or another which supports the format, installed). Can you give an example where sending the raw file would be a problem? I'm not aware of any existing Activity that matches your description. I'm not saying conversion to PDF is useless. For example, Write's user interface is not well optimized for reading books, and Read has not yet gained support for opening ODT (I believe). Therefore, an ODT-PDF converter would be a useful bridge. However, it's certainly not the ideal solution. Remember: we are trying to produce an editable world. Read and Write should be a single Activity, were it not for technical issues. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknClB0ACgkQUJT6e6HFtqTavQCfcoR+9piiALjs/ivMRa8tT/Ws ZYMAn2xwSx7stMDnYqwyp0OA5MzI6zJ8 =9EcK -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
I see your point, I agree. I will do the elimination as is required, and this time include a milestones/deadlines in my hopefully final draft proposal. My main objective will be to send the file from the laptop through the network to the server, have the necessary code for it both sides.(and ofcourse write UIs). (I'm actually having good experience with client-server projects) But if I should finish this earlier than the GSoC time span, and have sufficient time I will work on print-to-pdf, or since I intend to become a contributor, I will focus on it as an interest. I'd very well like to see myself implement this, so I will do this! So Ben, do I write print-to-pdf in my proposal or not? and if I do, what would be the best way to do it? On Fri, Mar 20, 2009 at 12:05 AM, Benjamin M. Schwartz Yes. There are lots of potential use cases that you might support, but you will not be able to support them all. I am suggesting that you approach this as a critical path problem. Do the absolute minimum amount of work necessary to achieve useful functionality in some situations, and then grow it from there. I agree the ability to convert things to PDF would be nice to have. I even proposed it as a feature of the Journal in June: http://lists.sugarlabs.org/archive/sugar-devel/2008-June/006598.html What I am saying here is: conversion to PDF within Sugar is not on the critical path to working print support. Well, that's fine. I just want to warn you against putting too many things into one Summer of Code proposal. Remember: most Summer of Code projects fail, because the project is too big and the code never reaches sufficient quality to be merged into the main codebase. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknCkFoACgkQUJT6e6HFtqQQEACcCmit2diezRw7Jsa3KW9UVuGo /msAniY1boOs/7GaXuDBnoZdjQ+7QKGQ =4kja -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vamsi Krishna Davuluri wrote: I see your point, I agree. I will do the elimination as is required, and this time include a milestones/deadlines in my hopefully final draft proposal. My main objective will be to send the file from the laptop through the network to the server, have the necessary code for it both sides.(and ofcourse write UIs). (I'm actually having good experience with client-server projects) But if I should finish this earlier than the GSoC time span, and have sufficient time I will work on print-to-pdf, or since I intend to become a contributor, I will focus on it as an interest. I'd very well like to see myself implement this, so I will do this! So Ben, do I write print-to-pdf in my proposal or not? and if I do, what would be the best way to do it? I think you just said it quite well. Your proposal can say which things you would like to do, and in what order you intend to do them. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknCl/AACgkQUJT6e6HFtqQwhQCgnycLuVAuVUEj3M/V1aZefa3Q OuUAn3SYrmcXW6/KIVHtyripAAmGB1bV =tfAx -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
vamsi krishna davuluri wrote: I see your point, I agree. I will do the elimination as is required, and this time include a milestones/deadlines in my hopefully final draft proposal. My main objective will be to send the file from the laptop through the network to the server, have the necessary code for it both sides.(and ofcourse write UIs). (I'm actually having good experience with client-server projects) i've only started reading this thread in the middle, so forgive me if i have this wrong: are you planning on installing all of CUPS on every laptop? if so, that seems very expensive from a disk space standpoint. (every megabyte counts on the XO.) the client code should be as lightweight as possible, even if it limits flexibility. (if someone, or some school, needs much greater flexibility, then perhaps an alternate printing client can be installed -- there's no need for one printing client to serve all needs. paul But if I should finish this earlier than the GSoC time span, and have sufficient time I will work on print-to-pdf, or since I intend to become a contributor, I will focus on it as an interest. I'd very well like to see myself implement this, so I will do this! So Ben, do I write print-to-pdf in my proposal or not? and if I do, what would be the best way to do it? On Fri, Mar 20, 2009 at 12:05 AM, Benjamin M. Schwartz Yes. There are lots of potential use cases that you might support, but you will not be able to support them all. I am suggesting that you approach this as a critical path problem. Do the absolute minimum amount of work necessary to achieve useful functionality in some situations, and then grow it from there. I agree the ability to convert things to PDF would be nice to have. I even proposed it as a feature of the Journal in June: http://lists.sugarlabs.org/archive/sugar-devel/2008-June/006598.html What I am saying here is: conversion to PDF within Sugar is not on the critical path to working print support. Well, that's fine. I just want to warn you against putting too many things into one Summer of Code proposal. Remember: most Summer of Code projects fail, because the project is too big and the code never reaches sufficient quality to be merged into the main codebase. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknCkFoACgkQUJT6e6HFtqQQEACcCmit2diezRw7Jsa3KW9UVuGo /msAniY1boOs/7GaXuDBnoZdjQ+7QKGQ =4kja -END PGP SIGNATURE- part 2 text/plain 153 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
On Thu, Mar 19, 2009 at 2:51 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: I have to agree that a print to pdf function could be useful, though, especially since it means that every activity can create output that can be transferred elsewhere (via email, USB drive, etc.) for printing. This provides a method, albeit indirect, for G1G1 users to print from various activities whose file formats are only understood by a Sugar activity. No, it doesn't. What we are discussing here is building PDF conversion functionality directly into Glucose. That means that the PDF renderer will support a fixed set of common file formats, corresponding to the output of a few popular Activities. At the moment, I am not aware of any Activity that produces printable data in a nonstandard format. Write produces Open Document Text. Record produces JPEG. Paint produces PNG. Therefore, these are the formats that the PDF renderer will support. Um, last time I checked there were a few more activities than these which might benefit from printing. Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
Wade Brainerd wrote: On Thu, Mar 19, 2009 at 2:51 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: I have to agree that a print to pdf function could be useful, though, especially since it means that every activity can create output that can be transferred elsewhere (via email, USB drive, etc.) for printing. This provides a method, albeit indirect, for G1G1 users to print from various activities whose file formats are only understood by a Sugar activity. No, it doesn't. What we are discussing here is building PDF conversion functionality directly into Glucose. That means that the PDF renderer will support a fixed set of common file formats, corresponding to the output of a few popular Activities. At the moment, I am not aware of any Activity that produces printable data in a nonstandard format. Write produces Open Document Text. Record produces JPEG. Paint produces PNG. Therefore, these are the formats that the PDF renderer will support. Um, last time I checked there were a few more activities than these which might benefit from printing. I was not aware of any existing Activity which saves printable images or documents to the Journal in a format that is not commonly used outside of Sugar. Since you protested I looked through the source code of Colors!, and sure enough, it seems to save Journal objects in its own special DRW format. Even so, it will not be easy to print from Colors!. What we have described so far is a non-interactive, fixed set of conversions to PDF, included with Glucose. To support DRW, we would have to include a complete duplicate copy of Colors!'s rendering engine with Sugar... and that will only work as long as Colors! doesn't change its output format. In order to permit printing from applications that don't save in any common format, we would have to create a much more complicated system, in which Activities somehow participate actively in the print conversion process. I'm not necessarily opposed to such a system, but it's a much larger undertaking than simply blessing a few common formats. It would probably be easier to add PNG export to Colors!. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
On 19 Mar 2009, at 20:34, Benjamin M. Schwartz wrote: Wade Brainerd wrote: On Thu, Mar 19, 2009 at 2:51 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: I have to agree that a print to pdf function could be useful, though, especially since it means that every activity can create output that can be transferred elsewhere (via email, USB drive, etc.) for printing. This provides a method, albeit indirect, for G1G1 users to print from various activities whose file formats are only understood by a Sugar activity. No, it doesn't. What we are discussing here is building PDF conversion functionality directly into Glucose. That means that the PDF renderer will support a fixed set of common file formats, corresponding to the output of a few popular Activities. At the moment, I am not aware of any Activity that produces printable data in a nonstandard format. Write produces Open Document Text. Record produces JPEG. Paint produces PNG. Therefore, these are the formats that the PDF renderer will support. Um, last time I checked there were a few more activities than these which might benefit from printing. I was not aware of any existing Activity which saves printable images or documents to the Journal in a format that is not commonly used outside of Sugar. Since you protested I looked through the source code of Colors!, and sure enough, it seems to save Journal objects in its own special DRW format. Even so, it will not be easy to print from Colors!. What we have described so far is a non-interactive, fixed set of conversions to PDF, included with Glucose. To support DRW, we would have to include a complete duplicate copy of Colors!'s rendering engine with Sugar... and that will only work as long as Colors! doesn't change its output format. In order to permit printing from applications that don't save in any common format, we would have to create a much more complicated system, in which Activities somehow participate actively in the print conversion process. I'm not necessarily opposed to such a system, but it's a much larger undertaking than simply blessing a few common formats. It would probably be easier to add PNG export to Colors!. Re PNG support in Colors!, yea I was looking for that a while back :-) in the end I took a screen grab and cropped. Just added feature request ticket: http://dev.sugarlabs.org/ticket/577 Regards, -Gary --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
Another use case is the student wants to print from home. The work may have been done at school then the student comes home, either using SoaS or with a laptop and now wants to print on the parent's computer. 2009/3/19 Vamsi Krishna Davuluri vamsi.davul...@gmail.com Hello! So here is a refined and less abstract approach for the Print Idea. (input credit Luke, Ben, Tomeu) Initial problem: where do we get the cups daemon/server from, and how do we have it working on python since its written in c? solution: The cups daemon would only need to be running on the core distro (add it as a dependency), and we have the amazing pycups bindings which wrap it up, so we can use in our configuration program and other apis which we will discuss. Now, that we have CUPS ready, lets step into implementing it problem 2: Interacting with the CUPS daemon to actually configure the printer solution: Debian has a python version of print-system-configure UI, hacking into the code will yield a decent template for fedora. Which can then be tailored to fit the sugar guidelines. problem 3: Who does the actual printing of the files?! solution: well, again there's these amazing pygtk print modules that take care of it. They make the CUPS API a backend, and work as a decent printing API, they again access the print-system-configure UI(or diving more deeply, the files postscript files (PPD) ) ( I have written a sample printing program demonstrating it on fedora) NOW LETS SUGARIZE THEM! (oh sweet sugar) problem4: We have everything ready but where do we put our print-system-conifguration? solution: we strip the debian (python based) UI, and dress it up with our nice sparkling UIs (the sugar design apis ) and put it in the control panel Here's where I propose an extra credit : Make the configuration An Interactive Wizard, (someone add groovy animations later on, or its on the end list on me) , as we will have to provide a default printer configuration at least once, despite cups having the ability to automatically select the printer. problem5: Okay, okay most of the job is done. Now where do we print from? answer: We print from that one place ofcourse, The Journal! (after all its he uncrowned king bad joke) As it is it is against the bitfrost system for a program to both access the network and the journal at the same time - secuirty constrictions. and also as to see that activity writers dont have to struggle with the print code, we can just see that the print requests are rendered into nice pdfs (CUPS again, we can print to pdfs) with the click of a magical button,store them at a known location and send those 'hit coordinates' and if any metadata by the IPC, and queue them up on journal for print. As an ACK send back a notification to the activity stating, You have a print job waiting, print it with default settings? or go to journal to edit settings Remember how i said pygtk can interact with the CUPS settings, well we will implement the relatively important ones in the journal as an option. Extra credit: I've been thinking about this make the school server take in network print requests (feasible/required or not? input please) Obscure stuff: CUPS server, Quota management, and permissions, CUPS server is a background process (hence daemon) which loopsback over the listening ports and ips. CUPS already benefits from a standard print quota management, the secrets of the implementation are in our debian configuration UI. permissions: ( I need input here) print permissions should be of any matter only if its a network assignment as far as i know. So what's the end result:: A nice interactive printer configuration wizard! Minimal work for the activity author! (an addition of 3 modules to print to pdf, but it will be of great value, as the user can present his work in as a pdf within the activity) Journal acting as print dock! pdf printing! And everything sugarized P.S. My actual application will be formal, please dont kill me :P Input Input Input please! Thank You Vamsi Krishna Davuluri ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
On Thu, Mar 19, 2009 at 4:34 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: I was not aware of any existing Activity which saves printable images or documents to the Journal in a format that is not commonly used outside of Sugar. Since you protested I looked through the source code of Colors!, and sure enough, it seems to save Journal objects in its own special DRW format. Yeah, pretty much every activity I have worked on has a custom format requirement. DRW for Colors!, JSON for Finance, JSON for Typing Turtle, etc. All of these activities could benefit from printing. That said, for Colors! I already implemented image transfer using the Copy feature. You can Copy to the Clipboard and the save the clipboard image to the Journal. I'll also consider adding a Save option to the Keep button, but I felt like Copy was ultimately more discoverable at the time. Either way though, how are we going to let users know what can be printed and what can't? We can't have them just arbitrarily clicking on various Journal entries, guessing at obscure copy schemes, etc. Personally I would be happiest with a Print button in the toolbar whose handler is responsible for saving to one of the common formats in a temp directory, and then passing that back to Sugar. Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
2009/3/19 Luke Faraone l...@faraone.cc: 2009/3/19 Caroline Meeks carol...@meekshome.com Another use case is the student wants to print from home. The work may have been done at school then the student comes home, either using SoaS or with a laptop and now wants to print on the parent's computer. For that use case, we're going to have to have some sort of install-as-needed service. Is there a way to do so that will be easilly discoverable? (I'm at a loss as to how that can be accomplished without requiring technical knowledge on the part of the user, or distro-specific fixes) Possibly stupid question, but why is CUPS that big? Does it have dependencies we could work on stripping? USB-based printing would be great IMO. Particularly when we're talking about kids with laptops other than the XO, in developed countries where printers at work and at home are more common. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
I was researching that, just extracting the print-pdf modules along with its dependencies and creating a new make (or package) should do the trick, but my knowledge limits me from seeing an implementation for it. On Fri, Mar 20, 2009 at 5:05 AM, Wade Brainerd wad...@gmail.com wrote: 2009/3/19 Luke Faraone l...@faraone.cc: 2009/3/19 Caroline Meeks carol...@meekshome.com Another use case is the student wants to print from home. The work may have been done at school then the student comes home, either using SoaS or with a laptop and now wants to print on the parent's computer. For that use case, we're going to have to have some sort of install-as-needed service. Is there a way to do so that will be easilly discoverable? (I'm at a loss as to how that can be accomplished without requiring technical knowledge on the part of the user, or distro-specific fixes) Possibly stupid question, but why is CUPS that big? Does it have dependencies we could work on stripping? USB-based printing would be great IMO. Particularly when we're talking about kids with laptops other than the XO, in developed countries where printers at work and at home are more common. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
