Okay, I never blogged this, my bad.

To sum up, about 2.5 weeks ago, I had made Print capable of USB printing.

Here are some screen shots:

I have yet to test the integration with the print device icon. I suppose it will work fine, because
the device icon works just fine for any usb print activity (last i checked with a printer).
For now it works like a charm for any file viewed in Print and which prints to Cups-PDF.

Feedback pleeaaaaaase 😀

p.s. Oh, the Print Setup will have an incarnation as a print dialog, but that’s a poll. 😉


Print Metamorphoses..

June 3, 2009


last week was pretty mundane, I was mostly with #moodle taking tips and trying to create a plugin for assignments that does printing, constraints uploads to PDFs and also displays them as thumbnails. Martin L had said there is definitely a much better way to do this, and we should be having a meeting this weekend.

From what I understood with moodle is the following:
Moodle has amazing extensibility:

1) It allows plugins to be placed with simple ‘tag’ code

2) You never have to build anything new for a moodle feature, It already exists within the core libraries (lib), you just need to properly play with it.

3) moodle has comments for every three lines of code

Only pitfall is, you can never figure out where to place new code, code which is non-moodle, that is:P

I had taken the existing upload assignments type plugin and made a new type print plugin, added new strings to get_string(). And played with the upload_lib.php so I could do pre-checks for PDF, and was looking up where exactly to put the thumbnail code. I guess this would have made my job quite trivial.



What I had proposed in my previous post is pretty much alive now. To sum up:

I made a 140 line basic print API that (for the time being only) parses filetypes like rtf and odt to cups-pdf, gets a temp pdf, and opens it in Print ( yes, this is the metamorphosis I was talking about, It is Print NOW!). And a new function in printactivity.py takes care of saving the pdfs. homunq had said saving a journal entry by default is good, I will have to edit it sometime.


*From my time with the pycups wrappers and system-config-printer, I’ve discovered that there is great scope to put print devices on share, or print to shared devices, display print queues, cancel jobs and what not. If only thing that might be of some work is, is the page config options. All this I sum upto a +300-400 lines of code in the print API.

Now comes the question of how to display all of this jargon to the sugar user. ‘How and When?’ .Tomeu had said he would help me on this one by posting a mail on the lists, I will also look up other activities and try to create mockups.

Andres and I got to do a few bugsquashing

And we were worried about Rainbow getting in the way, as cups-pdf could save to locations beyond rainbow provided freedom. Thanks to a discussion with Benjamin M. Schwartz, that got sorted out.

And I got around to making this function today:.

def _printPDF (self, _printer, _filename, _title = None):

Plan for the following week:
* Make Mock-ups
* Talk with Andres and team about where everything(such as queues, printer selection etc) would show up
* Talk with Martin and get the moodle plan sketched
* If all works out write out a rigid deadline for each week.

And when I’m not doing any of that:
* Code on elongating the sugar Print API

What is this about?

The last ODFTOPS script was pretty generic, it was done keeping in mind only the abiword 2.6.8 version. So here we have a pretty efficient script which works checking for capabilities a specific version of abiword would have, and writes the PostScript accordingly for maximum efficiency.

Did I stumble into any glitches while making this?

Yes, in fact the problem was I didn’t realize that CUPS and its executioner the lp user write to their own special TMPDIR, and when I was debugging defining it to /tmp/ , it wouldn’t work. Also the new script invites subshells, so we dont have to mess with system specific messages like “Aborted” and/or abiword specific messages. But SubShells could not write in the lp user’s TMPDIR, so I had to make define a TMPDIR1 in /tmp/, so as to perform the subshell related operations there.

Do we have an algorithm for the approach?

Yes, we do.
1) Check if abiword can output to different folders other than the one in which the input file is in. Meaning we would be checking if our abiword is 2.6.6+
for that output to .doc, so that we wouldnt be crossing out 2.6.8, as it can write to other folders, but not output directly as .ps
2) if true, check if its abiword 2.6.8, so that we do an intermediate doc conversion and then proceed
3) Else, just convert to ps directly
4) if 2.6.6–, then do a cp into the cups defined tmp dir and then perform operations

Where is the code?

The filter code

Thats about it.

Current Activities
* I am currently reading the D-BUS Specification, so I get a grip on how our IPC model works, and how objects are handled in read.

Current Design scheme for the fork of Read, i.e. The Print Activity, that I am following is,
1) Abandon edit, as the print activity is meant only for preview purposes, the parent activity is better imo for editing
2) Make a new toolbar to Open and close documents from within the journal. Also make a Print toolbar
3) Implement a module which converts odt to pdf using pycups code, and in the end results in that pdf being displayed
4) Add pycups code as a handler to another print button, and save that already converted pdf into journal as the execution for the PDFify button
5) As a bonus configure the pycups print configuration features realistically based on how our document looks in the Print activity. Essentially this would mean, add pycups code in each module of the Print activity for configuring.

I’m open for suggestions on this design scheme. Also, I’ve started work only on the most generic features, I will proceed with the actual design once we agree on it.

*trumpets and drums*
The Filter Code!
And thus, we have a filter for ODF!

The part that lagged this was the lack of my knowledge to do a chmod on the filter so that it could be written and read by all,
and SELINUX , and the lack of knowledge that a filter cant write to user directories (that was the biggest part, as the sample program would work but this wouldn’t)

Anyway, what you should do to make it work ( I will make a package for this soon)

1) Open terminal in SU mode 'gedit /etc/cups/odftops.types'
# Local MIME definition for ODT files
application/vnd.oasis.opendocument.text odt
and save
2) in terminal/konsole 'gedit /etc/cups/odftops.convs'
# Local ODT to PostScript filter for CUPS
application/vnd.oasis.opendocument.text application/postscript 100 odftops
and save
3) again do a 'gedit /usr/lib/cups/filter/odftops'
Paste the pastebin code in it and save
4) now do a 'chmod 777 (or 755) /usr/lib/cups/filter/odftops' under root
and then do a restorecon

and voila we have a odt filter set up. 🙂
of course libabiword is a dependency

CUPS-PDF can print from virtually any format, provided we have the filter for it (i.e. one can convert that mime type/ format to PostScript)
And so it happens that there isn’t a filter made for ODF to PS made yet, but there is still hope. People have already provided tutorials on how to add filters to CUPS. For instance IBM’s DVI Filter
tutorial is pretty handy. And this post seems to be pretty in-depth Filter Guide

I have already been working on a filter for ODT, it doesnt quite do an efficient job, and I messed it up bigtime (For the time being)

So anyway, it does conversion like this( since abiword cant directly write PS out of odt (due to bug 11247? ) for the current version)

converts odt ->doc->ps. There is notable quality drop, but not major, the pictures look a bit blurred out, thats about it.
All the formats, rulers etc are the same.

I will GIT this up as soon as I finish this. Got these exams to contend with for the time being 😦