Librerator - multi-format e-reader, fork of KPV

[ondasalfa]

I agree with dimasic, that is the most aesthetic and more practical

[knc1]

Originally Posted by dimasic

Lua's type conversion made me crazy. But when my code has made screenshot with its own colors, I suddenly noticed that the code is almost identical to the NuPogodi's code (after he made some corrections).

In resulting file the high and the low bits are still equal, so the tiny loss of contrast in highlights should be. But who cares?

Lua's type conversion ? ?
What type conversion ?
It is 8-bit clean strings.

If the high nibble == the low nibble (which it does) on reading from the frame buffer just divide the byte by 16 (right shift 4).
That gives 0 ... 15 right justified in the byte.

If the high nibble == 0 and data is in low nibble from you pbm file on writing, just duplicate the low for bits ( val + (val * 16)) in the byte to be written.

Not exactly brain surgery here - just simple math.
Even easier if using Lua 5.2 (which has bit ops) or your using the Lua 5.1 on the Kindles (just load the luabit library for bit ops).

[dimasic]

Originally Posted by knc1

Lua's type conversion ? ?
What type conversion ?
It is 8-bit clean strings.

Heh. When we read bytestring from framebuffer and parse it byte by byte with string:char and try to write them to output file, then we will get not bytestring, but string of hexadecimal representation of symbols. "0" from framebuffer will be "30" char string in output file as the NuPogodi's code (before correction) and dozen of my tries (before I found the right way) made. It's very strange at the first glance that there's no way to get bytes from string directly, without string:byte + string:char conversion.

If the high nibble == the low nibble (which it does) on reading from the frame buffer just divide the byte by 16 (right shift 4).
That gives 0 ... 15 right justified in the byte.

I know this. But when we divide the XX byte by 16 and then multiply the result by 16, we'll got X0. It's the right thing we want to get, but not in the case of FF - we'll got F0 and the greyish background in screenshot. When we are solving the problem by mathematical, not the bitewise ops, we must add the "if - then" case for FF bytes. IMHO, XX bytes instead of X0 in the resulting file are not the problem at all, but our code is more simple, without if-then and math.floor.

Not exactly brain surgery here - just simple math.
Even easier if using Lua 5.2 (which has bit ops) or your using the Lua 5.1 on the Kindles (just load the luabit library for bit ops).

Yes, I've found that the external libraries of bitewise ops are exist. But I think that is not very much reasonable to add them into distribution as we need them only once.

Anyway, thank you!

[Kai771]

Originally Posted by dimasic

A couple of thoughts about BBox feature.
It would be nice if in "Fit to content" and "Fit to height" modes narrow page will center on the screen (now it aligns left and looks not very much aesthetic).

If you're talking about tall narrow pages - they are centered on the screen.

If you're talking about long narrow pages (landscape), I don't agree that they should be centered. Pages like that are most likely 2 pages scanned together, or double page of manga/comics. In both cases, you won't be able to read them if they're centered. That's why it's aligned to top left if RTL mode is off, and top right if RTL mode is on.

If it is some rare poetry book or something, with a lot of margin space, just use BBox and fit-to-content-width. You don't have to set top and bottom BBox line. As a matter of fact, I always move just the left and right edge when setting it, and don't bother with top and bottom.

Edit: Oh, I forgot... you can get long narrow pages centered if you turn off comics mode and use fit-to-page-height.

Regards,
Kai

[dimasic]

Turning on/off the comics mode does not change anything in my case.

Well, I'll try to explain. My English is quite poor, but I'll try.

I opened a djvu file, set BBox leaving small white margins on the left and right of the text. When I turn on "Fit to content" or "Fit to content height" mode, the left margin (white field) is that, which I set by BBox, but the settings of the right one is ignored - the right margin is bigger than I set, it continues from text to the page edge. The pages are centered by the grey fields on the left and right, but the white margins are wrong.

It looks ugly enough, and I expected the other result. If I set the right margin, I would like to use it, won't I? But the setting of right margin does matter only in "Fit to content width" mode, not in other "content" modes.

Now I'll attach a couple of screenshots to make it clear. The same page with the same settings of BBox, but in the different modes - "Fit to content" and "Fit to content width". The "Fit to content height" treats the same way as "Fit to content".

[Kai771]

@dimasic

Ah, I see what you mean now. Well, setting BBox doesn't cut out that part of the page, and shows only that - it's only used to decide how to position the existing page. You see the white margin on the right, because there is space for that part of the page to be shown on screen.

It just isn't supposed to work the way you want it to.

That said, why would you want to use fit-to-height anyway? Isn't it more natural to use Fit-to-content-Width?

Fit-to-content will be the same as Fit-to-content-width if the content is wider than it's high, and vice versa - it will be the same as Fit-to-content-height if it's higher than it's wide.

You have one other option - you can set the background colour to white in defaults.lua, instead of default gray .

Regards,
Kai

[dimasic]

Yes, I know how it works - BBox doesn't cut the image, but shows the part of it through something like window or viewport, the zoom mode just calculates and sets the zoom level, and we can pan (move) the image to the right or to the left relative to viewport. But if the left margin can be set in the "Fit to content" / "content height" modes, why the right can't? The grey fields should be slightly more, whilst the right white margin - slightly less, and the content set with BBox should be centered. The content itself, not the content plus all the right margin to the page edge. I think.

Using of the "Fit to content width" gives us the more zoom and more comfortable reading, but the page can be shown not the whole - if it is tall and narrow - and the tiny part of it is hidden on the next screen. In comics mode it's hard to realise where the current line of reading is. If we read text, of course, not staring on pictures. The overlap shading doesn't help at all - this function is very buggy. That's why in this case (when the second part of page is really tiny) it's better to use fitting to content / content height. And it's all OK, but the fact that the content is not centered bothers me a little bit. I'm an perfectionist, you see.

The setting of grey background to white color is not our way. I see into the code and try to understand how it works. Offset_x and offset_y set the grey fields - I know, but I'm not sure how work pan_x, _y, _x1, _y1 and in which place of code they are set. Setting the different values of them in corresponding section of setzoom() does not make the visual difference, so probably they're really set somewhere else. "offset_" does, but not "pan_"

[Kai771]

@dimasic

Well, not showing the white margin to the left of a BBox is a bug. But, you're right - no matter if it shows content of the page left and right of BBox lines, the content (what's within left and right BBox lines) should be centered. This mode is not used all that much, so as a result, it wasn't tested all that much. Thanks for pointing it out.

Personally, when I read texts, I use Fit-to-content-width, and almost always there's a few lines left for another view. But, I don't use overlap. I tend to pan down as soon as I finish the top paragraph, so I don't have too much trouble to find where to continue reading.

Can you provide examples of buggy behaviour of overlap shading option?

Regards,
Kai

[dimasic]

Here you are!

Settings: "Fit to content width", "Overlap shading on", "Comics mode on" (as in "CM off" mode "OS on" does almost nothing, except of greying out up to couple of text strings). The pages are tall and don't fit to the screen. The text is black (screen1.png), we press the "next page" to move to the rest of the page. This rest of the page (the text) is black and the part we have read is grey (screen2.png). It's all OK. But if we move backward, to the beginning of the page, we get the picture, in which only small upper part of the text is black, but the bigger part of it is grey (screen3.png). All the page should be black because of a human reads from up to down and because of just one page turn before we saw the text in black and because of the grey page looks very uncomfortable.

The reading of miscellaneous handbooks means seeking forward and backward through the book, and such behavior of overlap shading bothers very much and makes overlap shading almost useless.

And it would be nice to turn on "Comics mode" automatically when the "Overlap shading" is on and to return to previous state of "CM", when overlapping is off. And probably to turn off overlapping shadow when we turn off CM. Some kind of AI.

[Kai771]

@dimasic

The behaviour you described is not a bug at all. It behaves as it should. Part of the page that was shown on the previous screen is shown as grayed out. It doesn't matter if it was shown as black or grayed out - if it was shown on previous screen, it will be grayed out on the current one. That's how it was intended to work. Pictures show that that's exactly the case. If you don't want to see gray text when going backwards, just turn overlap shading off before it, and turn it back on before you go forward again. Or, press backward once more, and then forward once. It might be a bit difficult to switch overlap on and off on K4NT, but it's only 1 key on K3, and quite easily usable.

Overlap shading is not useless if the comics mode is off, because Librerator overlaps 30 pixels by default. Meaning, 30 pixels from the bottom of the previous view will be on top of the next view. (Remember, Overlap shading grays out what was shown on previous screen). Depending on the font, sometimes it will be 1 line, sometimes 3, sometimes 1 and a half - so overlap shading helps find where to continue reading to the people that want it.

As I already explained, both Comics mode and Overlap shading have independent uses, and having one automatically turn on or off the other is not a good idea. You shouldn't assume that what works for you would work for everyone else.

I, for example, don't use Overlap shading, and always use Comics mode. I pan down early, on paragraph break. Depending on the text, this is not always possible. So sometimes, very rarely, I turn Overlap shading on for just a second, to see where I was, then turn it immediately off. It's quite easy to do this on K3.

Other people, for example, don't like comics mode. Especially if they mostly read novels. Some of them might still prefer overlap shading.

To each his own.

Regards,
Kai

[dimasic]

So do you think that when we turn the page forward by one step and backward (by one step too), it should become almost all greyed out? I don't understand why and what for. When we read the remain of the page at the bottom (it's black and the upper part is grey) and then return to the upper part of the page, we don't see the bottom, but do see only the main part. So why it's grey? Maybe to damage my eyes? Okay, I won't use this mode at all. If this is not a bug, but feature, this feature is not looks reasonable. To make the text black as it was, I should press two more buttons - backward and forward? So for simple returning to the previous page which was black I should press THREE buttons (back-back-fwd), not one. Oh, no. No, thank you.

[Kai771]

What will become gray depends on what was shown on the previous screen. You're only having in mind your case, where you only have a few lines on the second screen. There are situations where both screens are roughly the same size. Going back doesn't always mean that you'd want to read the whole page. What if you wanted to read only the top paragraph, that wasn't shown completely on the 2nd screen?

The function is called overlap shading. Whatever is "overlap" (content shown on previous screen) is shaded. Perfectly logical if you ask me. There is no such thing as "main part" - if it was shown on the previuos screen - it's overlap. It is gray to indicate that it was shown on previous screen. What you actually want is overlap shading working just in forward direction. It might suit you, but would probably not suit someone else.

[NuPogodi]

Originally Posted by dimasic

Okay, I won't use this mode at all. If this is not a bug, but feature, this feature is not looks reasonable.

Until you develop your own reader, you are not the person authorized to decide whether some feature is reasonable or not -- Quod licet Jovi, nоn licet bovi. Everything you can do is either to adjust the parameter show_overlap_enable or to quit using the reader. C’est la vie...

[dimasic]

NuPogodi, you should say: "Sperva dobeysya!"

[NuPogodi]

Originally Posted by dimasic

NuPogodi, you should say: "Sperva dobeysya!"

I'm just trying to explain you that most implemented features were discussed zillion times before they were finally implemented. Instead of forcing someone (i.e. the developer) to follow your personal requests that do not fit his reader concept, you should just copy the sources from github & change everything you want to. That's the way it is.

@Kai771: as we started to discuss the overlap, i've just recalled my old intention I've totally forgotten: iirc, the points inside overlapped areas are processed twice -- first, when the reader engines (mupdf, crengine, etc) parse the page and fill the framebuffer by the point colors (see c-functions usually called drawCurrentPage) and then, if the overlap is on, again -- dimRect reads the colors of points inside the overlapped area & halves them. It could be treated as not a big deal, unless this procedure is repeated for each damned book page. I was intended to write new cre-function drawOverlappedPage [including the overlapping area as input parameter -- actually, just y1 & y2 that mark overlapped area] and thus to avoid double-processing.
PS. Not a request, just an info that could also help you to improve the reader performance