Add basic border-radius support

[Frenzie]

See #628 for more details.

Basic test case: border-radius.html

What works:

• regular solid border-radius with background-color and background-image

What doesn't work as nicely yet:

• border-style other than solid

For example here it is with dotted (which looks like squares instead of dots but that's a separate pre-existing issue).

---

This change is 

[Frenzie]

All of these guards should be obsolete due to being precomputed now.

[poire-z]

Maybe move the new ones near the other imp_bit_border*, I'd like imp_bit_cr_hint to keep being the last one.

[poire-z]

The initiall value seems to be 0 : https://developer.mozilla.org/en-US/docs/Web/CSS/border-top-left-radius.
which would be css_length_t(css_val_screen_px, 0);, which is the default value for a css_lenght_t, so these may not ne needed (see the comment at the top of this block:

        // css_length_t fields are initialized by css_length_tag()
        // to (css_val_screen_px, 0)
        // The following ones  should not.

It is also what is used later/below in the changes when handling "initial":

                            if ( g == css_g_initial ) {
                                buf<<(lUInt32) css_val_screen_px; // type
                                buf<<(lUInt32) 0;                 // value

UNLESS this css_val_unspecified is used as a flag to skip the border radius computing stuff.

Anyway, these 2 snippets should use the same value (I checked a few of my if ( g >=0 ) and they are consistent with the stuff in lvstyles.h.

[poire-z]

Many changes of variable names, here and above (x => ix). May be you could ask the AI to "avoid changes in existing variable names to keep the diff small" ?)

I can't (don't want to and not competent enough :)) the drawing/math code :/

[Frenzie]

This is what I said in my comment: the reason it was named xx went away. Only x remains. But yes, the diff could be made slightly smaller by normalizing it to a somewhat confusing xx (because where's x then).

[poire-z]

You could move them nearer the other normal cssd_border_* above - border-collapse and border-spacing are more related to <table> than generic borders.
The parsing just below has been placed in the correct place for me, after the generic cssd_border_* and before cssd_background_image.

[poire-z]

AI bot is making his home in my living room :) You should add to the prompt "try to guess and avoid @poire-z 's anal retentive nitpicks from his past reviews" !

These helpers do not need to be at the start of the file, between unrelated stuff. There should be near where they are used, just before void DrawBorder I think.

Are these comments yours or the bot's ?
Not reviewing all these maths. I guess that if emited by the AI, there's no risk of typos and indices update forgotten from copying&pasting from the first implemented TL into the 3 other corners.

[Frenzie]

The risk from AI paraphrasing the same thing you wrote elsewhere is both smaller and much larger (it probably won't typo, but it might add weird stuff). But when it's incorrect, the border looks visually very wrong.

The comments are nice when hovering over where a function is used to see what it does. The order of corners stuff is perhaps slightly redundant but border-radius is quite unique and everything else border goes top, right, bottom, left. It's something I tend to have to remind myself of (mainly whether it starts TL or TR). Was there something specific that bothered you about them?

[poire-z]

No, nothing bothering. I just wondered if the comments were yours or rewritten by you (I haven't even read them :/).
And generally, how much (if any) tweaks by your fingers to the AI output ?

I'd just like this whole section to be moved near void DrawBorder.

[poire-z]

Here, if we get (css_val_screen_px,0) (that we get with initial), we would go compute lenghToPx() while it's not needed ?

[poire-z]

This computeBorderRadiiPx() is called here for any block element, so it ought to be optimized.

[poire-z]

These (defined above:

            bool restore_rounded = false;
            lvRect saved_rounded_rect;
            int saved_rx[4] = {0,0,0,0};
            int saved_ry[4] = {0,0,0,0};
            bool saved_active = false;
            if (dei) {
                // Save prev state
                saved_active = dei->rounded_clip_active;
                saved_rounded_rect = dei->rounded_clip_rect;
                for (int i=0;i<4;i++){ saved_rx[i]=dei->rounded_rx[i]; saved_ry[i]=dei->rounded_ry[i]; }

) could have better names and similar prefixes, restore_xyz matching saved_xyy, ie.

            if (restore_rounded_clip) {
                // Restore original rounded state
                dei->rounded_clip_active = saved_rounded_clip_active;
                dei->rounded_clip_rect = saved_rounded_clip_rect;
                for (int i=0;i<4;i++){ dei->rounded_clip_rx[i]=saved_rounded_clip_rx[i]; ...

(just wrote that quickly, may be wrong).

[poire-z]

computeBorderRadiiPx() already does the rx[0]||rx[1]..., so it could return a bool (has_rounded_border) so we don't need to redo-it.

[poire-z]

Not fun having to review some AI output :/ but as you have been doing this to improve @offset-torque 's weak trust and love for crengine:

koreader/koreader.github.io#59 (comment)

EPUB: This has to be rendered using KOReader engine, which is very limited. Even 18 years old CSS features are not supported. Also I had problems with embedded fonts. Result is degraded readability and document looks straight out of 70's.

koreader/koreader.github.io#59 (comment)

Surely but in this case missing features harms readability. For example now I can highlight UI related words with a "dashed rounded border" which is visible but not distracting the flow. Without this feature, I had to use a rectangle solid border which turned the page into a redacted government document :)

I'm fine with that :)
Also check it works with borders/padding/margin on inline elements (I guess it uses the same code, but please check to be sure).

[poire-z]

Pinging @NiLuJe and @benoit-pierre for a quick review of the AI computing/drawing code (you both have hacked images/drawing stuff in the past, so you'll probably have a better feel for its quality than me).

[Frenzie]

Not fun having to review some AI output :/

Most of your comments are directed at me, not to worry.

but as you have been doing this to improve @offset-torque 's weak trust and love for crengine:

This you guessed correctly.

[offset-torque]

but as you have been doing this to improve offset-torque 's weak trust and love for crengine:

My intention was not throwing shade on crengine, really :) I think KOReader does its job very well. EPUBs I read are generally very simple and with all the customization options and style tweaks they render perfectly. This lack of css features never inconvenienced me when reading EPUBs. And fancy formatted books/scientific articles already come in PDF format.

I was specifically talking about the user guide there, which is a more demanding document - closer to a CS book instead of a novel with all the infoboxes, menu breadcrumbs, links... So the guide is more usable as a HTML document or a PDF instead of a downgraded EPUB especially considering the monochrome color restriction. And this is not KOReader's fault of course.

[poire-z]

@Frenzie : tired of whiping your AI slave on this PR ? :)

[Frenzie]

I'll probably pick it back up sometime. I may have made a mistake when I told it to copy the logic for the bg image since that made it all much larger. :-)