Printing from Print (sugar) just works (too)

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:
screen1
screen2

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. 😉

Printing from moodle just works.

As the title speaks, Printing from Moodle just works.
Screen1
Screen2
A few things to note, the thing is still messed up. There is quite a lot of work to be done.
1) Add a settings page for the administrator (global File upload limit*)
2) Clean the UI messages
3) Get the messy XML-RPC code working! ( I cant figure out how to save the sent binary data as a pdf…)

If that’s done 85%-90% of this project will be done.

Tim (from Moodle) and Martin had suggested I redo my module as a block, BUT my idea was before I pull out something new, get at least this working completely so I have a backup.
So anyway, apologies for the late update, but fighting with xml-rpc is taking longer, and I had been travelling too.

The Printer Device Icon

The XS installation leached away almost a week of mine, the previous one I mean. And with moodle I have officially wasted 2 weeks, hence to avoid not being productive at all, I’ve decided to finish the sugar side asap, and at least get a working model done here soon:

After a kick start from Andres, and looking up D-BUS tutorials and the HAL spec,
and of course extracting source from system-config-printer, and hacking our own Network device icon, and volume device icon, I have written a Printer Device Icon
here is the code for it:
code

and here’s how it looks:
Image

Feedback most welcome!

Moodle plan sketched!

Talking to Martin Langhoff had been VERY helpful, I now have an architecture to work on:

1)As pointed by Dave( thanks Dave), we already have implementation that sets a cookie and authenticates users courtesy the webactivity
And Martin had said auth/olpcxs/auth.php should yield good stuff on the implementation.
2) The two ways this would be integrated into moodle could be:
i) As a new tab under the moodle’s user page
ii) As a module under courses

Both have use-cases ,
for i) This can be a global event without any relevance to courses, so one wont have to really be in a course to use printing.
ii) having this within a course allows group management to be easy, and we could easily restrict which teacher gets to accept/reject printing for which student
I’m inclined towards ii) as implementation wise, and use-case wise that seems to have an upper hand.

Now to sketch a detailed plan for 3 weeks to come:

week-1:
Authenticate myself, and send files under a specific user, via HTTP-POST vs XML-RPC.
Start building a skeleton for a new module under courses.

week-2:
fill it with a print queue, based on cron.php. also in case a teacher logs in, have a print button when ever a printer is available.

week-3:
fill it with anything else that is left. Get back to sugar part.
————-

Also, so far my moodle expeditions only lead to a better undertsanding of how the system works.
Last week was adding a few more bug fixes to the print activity, and code- and-prune moodle side.
And mostly testing new theories.

So anyway since i have concrete goals this time, I should do this asap.
A detailed discussion can be found here:
Moodle-Print

Print Metamorphoses..

Hi!

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.

#closeMoodle

#enterSugar

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.

http://git.sugarlabs.org/projects/read/repos/print

*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

A revision, and current events

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.

The Shady ODF is no more Shady enough (ODF Filter for CUPS)

*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

An Introduction, if a little late

Hi!
I’m introduced to the sugar community through GSoC, and my project is adding print support to the XO laptops in a teacher controlled environment (which is the primary case) and the secondary would be to see to it that even network printing can be done.

And as for me I am a 3rd year engineering student from Chennai, India. I was always fascinated by this feature:
hit a button and see the object on screen move, it always made me think I was supreme if in a constrained environment.

Though I want to pursue more Mathematical/statistical and pure computer science specific research areas in the future,
User Interfaces and networking have been two things that are very integral to a programmers life. So I would like to learn some awesome things in this area with this project of mine.

Later!

Sugarizing the blog

Well folks, random question, do we need a better, more sugary layout?

Filtering a robust yet, shady format (ODF)

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 😦