KPV: a PDF reader for Kindle, based on muPDF, GPLv3

[twobob]

It does. I agree with your points.

Might I politely suggest you consider having a shufty at buildroot.

Since you are "a noob" (although I think after building that we can safely term you "blooded") that will undoubtedly seem like fun. Your new found skills with Make certainly will have a home there.

(Perhaps you could inject KPDF into the make packages, a completely kindle app in the tree, With a completely hand built make, that would be cool, BR supports home-madey makes )


As you can see I really have no answers, only ideas, I appreciate your take on the TC's
I am certain KNC meant well.

In other news if you are up for it I could REALLY use some help getting doom going...

Just a thought.

In answer to your question I'm going to dump some 3 stuff on a 5 straight out of buildroot via the CS 2007q3 and see what happens. LOL.

Answers soon.

[knc1]

Originally Posted by Kai771

Since I never tried compiling anything other than kpdfv, these are just speculations of a noob, but I'd expect most other apps would work with the latest CS/MG, given the same switches used with kpdfv. I think that if you use the latest source of any opensource project you'd like to build, it will require more recent gcc than 4.2, if not now, then soon. So personally, I'd go with the latest, and regress if necessary.

Any objective is worthy of a specific description.

For new work, if your objective is to compile code targeted at a device that uses recent glibc system libraries,
then that requires a gcc version newer than 4.2 to compile those glibc system libraries.
That objective in itself sets a minimum gcc version.
Neither the vendor of the gcc version, the target of the compilation, nor the producer of the gcc compiler binaries is relevant in the selection of the minimum gcc version.

For work targeting an existing system, then the type and version of the existing system libraries may (is likely to) set a different minimum gcc version. This sort of objective may also set a maximum gcc version. It may also set other limits to the selection of the gcc version.
The prime deciding factor is the type and version of the system libraries being run by the targeted existing system.

For work targeting an existing Kindle system, just stating the objective as "a Kindle system" is not a specific enough to qualify the objective.
The Kindle models, and the software system that runs them, has evolved over time. Not all Kindle models run the same type and version of system libraries.
A person's choice in this situation is to better qualify the objective.
If qualified as a specific Kindle model, then that specifies the type and version of system libraries the work is targeted at and that in turn may set requirements on gcc version, per the above.

Originally Posted by Kai771

Regarding Linaro, I think that it might be better than CS/MG. It seems Linaro is pretty popular with building android roms, for example. However, it won't work out of the box (on K3. I think it works out of the box on K5). To make it work on K3, you'd have to build it yourself. I'm reluctant to do it, at least for now. It might not be that hard, but... idk, it seems like too much work for me. So I think I'll stick with CS/MG for now.

There is another consideration to be made, that is not included in the above statements.
Which CS/MG release process is being discussed.
The "for purchase" version, generally released at 3 month intervals and updated during its deployment, will be very close (within 3 months or closer) to the Linaro versions.
The "for free" version, will always be at least 6 to 9 months older than the Linaro project.
This is an artifact of the company not releasing the sources to the current "for purchase" version until that version has been replaced.
With CS/MG - to get a tool-chain comparable to the Linaro project, you have to purchase the binary builds.

It is misleading to compare Apples and 9 month old Oranges.

The Linaro project targets only the ARM processors. A single focus project.
The CS/MG targets most of the common processors used in the world of embedded systems. A multiple focus project. This can reduce the degree of attention paid to any single processor target.
These two large, for-profit, corporations do not work in a vacuum. They both publish their changes to the upstream projects. What gets fixed by one will appear in the sources of the other through the commonality of the upstream projects.

The GPLv2, section 3 requires the release of "all scripts and other files ..." I.E: Everything required to duplicate the binary from the sources.

For Linaro, they use the crosstool-ng build system to create their binary releases. They also post the complete crosstool-ng system used "as configured" with each release of the sources and binaries they make.
You only have to run the crosstool-ng system, with possibly changes in its configuration to match your fully qualified objective.

For CS/MG, they include all of the scripting and configuration they used in the source bundle for each release.
You only have to run it the way they ran it, again with possible changes in its configuration to match your fully qualified objective.

No "invented here" build effort required in either case (other than your local changes to the configuration).

Originally Posted by Kai771

If I were to build Linaro, however, I'd go for the latest stable release, and build that. Bleeding edge is, well... too bleeding edge for me . In my opinion, bleeding edge is for experts, and since I'm just a noob, it's clearly not for me.

Correct me if I'm wrong, but don't apps built for K3 (nano for example) work on K5? If so, I'd use armv6 etc settings for all but performance critical apps (for example, nano doesn't need to be optimized for armv7. Some Video codec, on the other hand...). Some might say it's because I only have K3, but I'm not a fan of optimizations for optimization sake.

Applications can be built to run on both the K3 and the K5 if and only if:
The lowest common denominator of the hardware resources is sufficient; and
(presuming from the non-specific context above: "using the Amazon-lab126 libraries that are pre-installed"):
The lowest common denominator of mutual compatibility between system libraries and kernel headers is used.

If claims of "ABI compatibility" are relied on in making the above configuration decisions, be prepared to discover and deal with any over-sights in those claims.

Originally Posted by Kai771

So, these are my opinions. I don't know how useful they may be to anyone, but I hope that answers your question .

As opinions on a general over-view of the situation, not bad.
As guidance for others, something more specific than generalized opinions is required.

For readers interested in entering this world of system's building . . . .
I strongly recommend that they take the time to work through at least one build of LFS (Linux From Scratch):
http://www.linuxfromscratch.org/lfs/

Once you master that, if interested in doing cross-system development, then I recommend that you work through that specialization of LFS:
http://trac.cross-lfs.org/

[twobob]

Built for a 3 with 3 flags...
splattered on 5...
[root@kindle root]# /mnt/us/usr/bin/gnuchess

GNU Chess 5.07
Adjusting HashSize to 1024 slots
Transposition table: Entries=1K Size=48K
Pawn hash table: Entries=0K Size=32K
White (1) :

works fine...

[twobob]

Yeah it's an interesting point about GPLv2 "You must include all configs"

Thought about that. In essence to fully comply one would have to provide the entire machine as a snapshot. sort of silly.

Went with: The full build folders and be damned

[knc1]

Originally Posted by twobob

Built for a 3 with 3 flags...
splattered on 5...
[root@kindle root]# /mnt/us/usr/bin/gnuchess

works fine...

Hey, I never discussed: "Luck" in my post. *

The above post was addressed to an audience that was at the point of their 2nd or 3rd try at compiling something.

Not at folks who are in their 2nd or 3rd decade of compiling things.

- - - -
* Actually, those buzz-words: "ABI compatibility" at work.

[knc1]

Originally Posted by twobob

Yeah it's an interesting point about GPLv2 "You must include all configs"

Thought about that. In essence to fully comply one would have to provide the entire machine as a snapshot. sort of silly.

Went with: The full build folders and be damned

That is a subject that has received a lot of attention on the Buildroot project mailing lists.
There has even been some efforts made to automate the process of GPL compliance in Buildroot.

But some of the commercial contractors using Buildroot have decided the same as yourself:
Tar-Ball the entire mess (exclusive of their proprietary, locally added, parts), drop it on the world and "be done with it".
Let "the world" sort it all out.

[swrd]

First of all ,It's a wonderful software.
Well we can custom the LINE SPACING by alt + pageup OR pagedown
font by shift+pageup OR pagedown
and how can i custom the margin of txt mobi or epubs

Is there some shortcut or should i edit the cr3.css or txt.css.
I NEED you helps.thx

[tigran]

The very latest (pre-release) version is available here:

https://github.com/tigran123/kindlepdfviewer/downloads

The more people download and test it the sooner you will get the official release

[dpavlin]

I just pushed new 2012.09 release to

https://github.com/hwhw/kindlepdfviewer/wiki/Download

Thanks to all developers for hard work, and I hope you will like it.

[Fred Vargas]

Originally Posted by dpavlin

I just pushed new 2012.09 release to

https://github.com/hwhw/kindlepdfviewer/wiki/Download

Thanks to all developers for hard work, and I hope you will like it.

what was already good, just got better

I use your reader at least 4hrs per day and i'm very happy. I only had a problem. Some vectorized objects in pdf - like dialogue box - make the page take a few minutes to change.

[Kai771]

Old hacks for the new release. They're first discussed here. Since some people did downloaded them, I thought maybe some of them need it. So here they are. Just unpack it and copy it over unireader.lua on your kindle. Changes contain:

1. Changing key bindings for Zoom to Fit to Content etc.
2. Removing dimming of overlapping content
3. Always fill screen with content of the page

[dave2008]

Originally Posted by swrd

First of all ,It's a wonderful software.
Well we can custom the LINE SPACING by alt + pageup OR pagedown
font by shift+pageup OR pagedown
and how can i custom the margin of txt mobi or epubs

Is there some shortcut or should i edit the cr3.css or txt.css.
I NEED you helps.thx

So far, there is no shortcut But it is in the TODO list.

Originally Posted by dpavlin

I just pushed new 2012.09 release to

https://github.com/hwhw/kindlepdfviewer/wiki/Download

Thanks to all developers for hard work, and I hope you will like it.

And all the users who reported bugs and helped with testing, especiall eLiNK and dracodoc

[dracodoc]

How can I change the font zoom step in crereader? I'm using some Chinese font for Chinese epub book, the current font zoom step is too big, I tried to edit the crereader.lua, changed the delta =0.5, but that doesn't work, it seemed to have to be integer.

[lokoroko]

Thanks for great program.

I've made two screenshots: one for default Kindle 3 (Keyboard) PDF reader and one for this one. You can add these screenshots in description to illustrate difference (and improvement) between readers.

[tigran]

Originally Posted by Kai771

Old hacks for the new release.
2. Removing dimming of overlapping content

Thanks, I implemented this feature as a per-book configurable (controlled via `O` command) in the PR #395, see here:

https://github.com/hwhw/kindlepdfviewer/pull/395

I haven't built the new kindlepdfviewer yet, probably will do tonight, it will be in the usual location:

https://github.com/tigran123/kindlepdfviewer/downloads