iLiad Fixing iPdf for iRex

[emkay]

Stick with it Matthijs!
Your work is much appreciated, as is your patience and good humour in dealing with all the iRex digs.

[scotty1024]

Originally Posted by Matthijs

@scotty: it would be beneficial to all of us if you supplied the sources to your versions of ipdf. I've branched the 2.7 version in our public repo so your changes can be easily made visible and ported.


Do you see any relation between the absence of the backstabbing, provocative and "look at me being superior and them being stupid" remarks on this forum and my drive to spend my precious time helping here?

It would be really beneficial if iRex would make the sources for their version of key libraries such as Poppler available. It would also be very helpful if iRex made their kernel sources available. It would also be very helpful if iRex supplied the long delayed hold-down-a-button-to-reload-firmware-from-media-card feature. And it would help iLiad developers everywhere if iRex released either JTAG support or a console cable.

In my opinion you are one of the "good guys" at iRex but your rice bowl is still filled by the success of the iLiad. Any time you spend helping make the iLiad more successful is helping keep that rice bowl filled and un-cracked.

The really precious time is that of people such as Antartica, Design256, Yokos et al whom are spending their personal time figuring out things iRex could have supplied thus allowing everyone to spend more of their precious personal time on producing cool software/ports.

I personally would rather spend my precious time on figuring out the best paragraph breaking algorithm for page layout in my iLiad RTF Viewer than reverse engineering Poppler to figure out which version iRex is using.

If iRex is ready to allow developers to submit check ins to the public repository sign me up.

[Matthijs]

We're not asking nor wanting you to reverse engineer these things; just focus on the stuff you can already do and wait with the kernel and lower level system actions until we can release the full sources and have a safe platform for such development available (read: unbrick from CF).

In my opinion the system is just not mature enough for any community development at the moment. The only reason why I assist and support you in doing it is that otherwise you would be using a home-built toolchain and doing even more guessing in the dark than you're doing already. There was no stopping you guys, but in an ideal world you would have waited for the full SDK. Why, you ask? Well, you have already experienced that we need to make changes to our libraries (erdm,erreg,eripc,erscribble) and other low-level interfaces. You will experience a lot more of this in the near future. This will likely frustrate people and you will need to change and re-compile your applications again and again.

I'm not saying you should give up; not at all! I guess my point is that I agree with you that the system is far from ideal for community development right now. I just don't think a fork of the whole iLiad software project would benefit us right now and that is what would happen if we released stuff as-is. IMO it needs to have a certain amount of structure before you can do that.

[CommanderROR]

Maybe you are right Matthijs, the problem however is...WHEN...
There have been promises of a "finished" Iliad for September, this is long past. The full SDK was "pushed back" to november, but that is also long gone now. I know that software development and release dates is not a loving couple, I've seen enough delays for programs and games in the past, but since this is Linux and OpenSource many users just expect to get the sources on DayOne. Of course, this would have meant that some kind of "FailSafe" would have had to be in place right from the start as well.

Well, it's too late to cry about things like that now. I hope things will progress smoothly from now on and that the changes from now on will be more than little updates to the PDF viewer.
Please never forget Matthijs, that all the bickering and yelling I (and many others) have been doing about iRex and at iRex is not directed at you, it's directed at the management that made some very weird decisions that still manages to annoy and frighten us Iliad users with strange and unexpected announcements and priorities (like the suspen fiasco...but i'm not going to get started on that again...)

You are doing an excellent job, supporting the community, keeping us all as happy as you can just like Karel and Angel did before the real lauch of the Iliad.
Thanks.

Now, back to the topic, whatever that was...

[scotty1024]

Originally Posted by Matthijs

We're not asking nor wanting you to reverse engineer these things; just focus on the stuff you can already do and wait with the kernel and lower level system actions until we can release the full sources and have a safe platform for such development available (read: unbrick from CF).

Actually you guys did ask me to reverse engineer Poppler!

Eventually I figured out the problem wasn't Poppler but was in reality that everyone had missed the obvious: Poppler doesn't have a Mono4!

I had a real Doh! moment when I realized that Mono8 was just fine, it just needed to be error dispersed into a Mono4 for the iLiad to display it. I assumed when you said you all had tried Mono8 yourselves and Poppler had problems... and made an ass out of myself as well. Countless hours tromping around in the Poppler sources and all I needed to have done was look at what was right there in front of me: perfectly good Mono8 waiting to be corrected into Mono4.

You sent me on quite the "wild goose chase".

Anyone can hack the kernel is perfect security via loadable kernel modules. No need for a CF recovery option. But its much easier to work with if you have the exact kernel source to compile the loadable modules from.

[scotty1024]

The deed is done.

First impressions of 2.8:

I miss my clock. I know I thought it was silly, then I hacked it into my iLiad, now I miss it.

Did I ever really think those moth eaten glyphs were razor sharp in PDF's?

I'll have an enhanced 2.8 ipdf later today.

I still have no "Average Joe" means of distributing the clock. Maybe another SED script to edit that ticklish file that will brick your iLiad if it doesn't get edited correctly...

[scotty1024]

Here is version 8 of my enhanced ipdf for 2.8 OS.

NOTE: this will NOT work on 2.7. Time to update to 2.8, I made it and all my toys too.

As with 2.7, iRex did not supply ipdf is a make-able state. I have yet to figure out what is so different about their autoconf but I can only get it to work in Antartica's tool chain under scratchbox. So this version is compiled with Antartica's tool chain. Another shout out to Antartica: Thanks!

This version has:
Save page number moved to top of quit logic, helps make sure your current page gets saved in case of crashes-on-exit.
Runs Poppler in Mono 8 mode, which renders pages more efficiently with smaller memory foot print. Should leave more electrons in your lithium ion tank per page render.
Uses my direct frame buffer logic, which is more efficient than iRex's version.
Has all the console debug messages turned off, I'm not certain why iRex leaves these turned on in production bits since they are not accessible to your average developer and otherwise just use CPU resources that could be spent elsewhere (like rendering pages.)
Uses my Mono 8 to Mono 4 code adapted from iRex's error distribution algorithm which is adapted from FS:
Doesn't create an XImage, reduced memory usage.
Works directly on Mono 8 rather than RGB so ARM CPU processes much more rapidly (doesn't overwhelm CPU registers, so it is far more than 3 times faster: 60ms vs 1200ms.)
Doesn't distribute errors for Mono 8 value 255, keeps rendered glyphs razor sharp and enhances scanned pages as well (Paul's and Google's ebooks)
No more RGB color cube color table setup logic and memory usage.

One sad note: no matrixy mode in this one. Not enough time for it to make the cut I'm afraid.

One usage note: continuous mode may or may not work. I haven't figured out how to use it in order to test it. Had to spend time re-installing my environment not on figuring out what they added to 2.8.

[CommanderROR]

Thanks a lot Scotty!!!

Just two things:
Does scribble still work?

And:
yokos? Can you make this a nice and comfortable package again like the older IDPF releases? Then I can install it...

[scotty1024]

Yes sir, it scribbles. I'm already plotting how to get my RTF Viewer, DJVU and Graphic Novel viewers up with scribble too...

What you witnessed was me taking the 2.8 code, getting it make-able, compiling it, testing it worked, then re-installing all of my enhancements with adjustments for genetic drift between 2.7 and 2.8 (by hand, no diff/patch). Compiling, testing, tweaking, posting...

What I'm unclear on at this point is if iRex wanted me to post the source so they could check it in or were they setting me up with an account to check it in?

This is where things broke down last time...

Enjoy the binary in the mean time, let me know if you find any issues.

[Matthijs]

As with 2.7, I have put the autoconf generated stuff in the tar.gz, not in the SVN repo (where it does not belong IMO). If you have problems with autoconf et al (it works fine out of the box on Ubuntu 6.06 LTS), use the tar.gz instead of the SVN release...

About poppler: the right place to fix this IS inside poppler if you want to do the error dispersion only on the images and not on the text. Your work-around will do fine as well, but still does error diffusion on everything.

As for the reverse engineering: I was talking about the kernel stuff. Also: I have sent you our version of poppler plus all of our patches in an email on November 17, which was the first time I was made aware of the fact that you did not know exactly which version to use.

As for the account to checkin to our public SVN: that might be a bit complicated. If you can supply me with a tarred up src dir, I'll gladly import it. That will be faster.

[scotty1024]

Originally Posted by Matthijs

As with 2.7, I have put the autoconf generated stuff in the tar.gz, not in the SVN repo (where it does not belong IMO). If you have problems with autoconf et al (it works fine out of the box on Ubuntu 6.06 LTS), use the tar.gz instead of the SVN release...

It may be that putting the autoconf package into the tool chain is needed. Even under Antartica's Scratchbox tool chain the ipdf autogen is being grudgingly processed. It looks like some of the ipdf config files are written using older semantics that they are trying to get people to upgrade away from.

[jæd]

Originally Posted by scotty1024

What I'm unclear on at this point is if iRex wanted me to post the source so they could check it in or were they setting me up with an account to check it in?

Why not just post the source here...? Or does it have NDA stuff...? Just think of the people who learn from your Accomplishment...?

[henkvdg]

Originally Posted by scotty1024

Here is version 8 of my enhanced ipdf for 2.8 OS.

NOTE: this will NOT work on 2.7. Time to update to 2.8, I made it and all my toys too.



One sad note: no matrixy mode in this one. Not enough time for it to make the cut I'm afraid.

So: black flash now. Difficult to distinguish from iRex's ipdf.

[Matthijs]

@henk: It should zoom faster and switch to pages that are not pre-rendered faster.

@jaed(/scotty): If Scotty uploads the sources to Mobileread as he has done for the 0.27_4 version, I will check them into our SVN repo in a branch, so it is very easy to see and merge the differences. Our server admin is ill at the moment and even so I'm not sure he will like the write access for people outside iRex.

@scotty: I'm not a real autotools guru myself, so if anyone here is and can point me to any mistakes or semantic errors in our *.am files, please feel free to do so.

[yokos]

@ scotty: your ipdfv8 [md5: 257c1177b262a538f32b0b2c15238701] is not compatible with a "clean" 2.8. I tested it, your pdf viewer doesn't start.

[EDIT I] ok, correction. ipdfv8 opens the most of my pdf files. Perpaps there is manifest.xml incompability [doesn't like some lines in file or so].
[EDIT II] Yes, ipdfv8 doesn't like some manifest.xml. I have moved pdf out of directory with manifest.xml & scribble.irx & then ipdfv8 opened pdf file. One of my "problem" manifest.xml is attached.
[EDIT III] in~ & deinstallation scripts [ipdf8_2.8.zip]