-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Background images enhancements, fix FB2 footnotes alignment #353
Conversation
Includes some small refactoring and changes needed for CoolReader Android build.
Not really needed, and avoid some checks.
For better support of the image original colors and transparency.
Including keywords "contain" and "cover". Remove parsed but unimplemented "background-attachment", which would anyway not make much sense to support: we behave as "background-attachment: scroll".
Just a matter of accepting this when parsing "background:" and "background-image:". What's been added to support <img src="data:image/png;base64,...> by c35d1b8 will then handle it when drawing background.
All elements (except PRE-like ones) should start with "white-space: inherit" and not "white-space: normal", so they don't cancel "white-space: pre" when they are children of a <PRE>. Only the root node is set to "white-space: normal", thal all children will inherit from (except when they get a speficied white-space: property value).
@@ -278,7 +278,6 @@ enum lvdom_element_render_method | |||
erm_block, ///< render as block element (render as containing other elements) | |||
erm_final, ///< final element: render the whole it's content as single render block | |||
erm_inline, ///< inline element | |||
erm_runin, ///< run-in (used as a solution to inline FB2 footnotes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a Norse mythological bird named something like Runin — I can't quite think of the name right now. I didn't immediately realize it said run-in. :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Muninn, (one of) Odin's raven (Memory, IIRC).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right, thanks. https://en.wikipedia.org/wiki/Huginn_and_Muninn
if ( bg_w.type == css_val_unspecified && bg_h.type == css_val_unspecified ) { | ||
if ( bg_w.value == css_generic_contain && bg_h.value == css_generic_contain ) { | ||
// Image should be fully contained in container (no crop) | ||
int scale_w = 1024 * container_w / img_w; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why 1024?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's reverted below when applied.
This is just to avoid int scale_w = 300 / 400
to be int 0
with int arithmetic.
Dunno if there's a proper way to do that :) @NiLuJe ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Short of storing the scale as a proper float
(which would imply also casting one of the DIV operands to float), not really.
See also https://en.wikipedia.org/wiki/Fixed-point_arithmetic & http://www.sunshine2k.de/articles/coding/fp/sunfp.html for more complex trickery (e.g., 16.16 is how FreeType does arithmetics).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I guess that we'll probably never have images or container larger than 65536px, so I guess I could use 65536 = 2^16 as the multiplier (instead of 1024 = 2^10), and we'll fit in a 32-bits int. Right ?
int scale_w = (container_w<<16) / img_w
[...]
new_h = (img_h * scale_w) >> 16;
Or there's some risk I don't see?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, unless it's a really hot code path, I'd probably jump the gun and use a float, nothing we run on lacks an FPU.
i.e., float scale_w = container_w / (float) img_w;
.
When going the other way around (i.e. int smthg = scale * int_somthg), the implicit cast will truncate by default, so you may need to ifloorf/iceilf/iroundf (which are C99 standard, and/or GCC/Clang builtins that return an int instead of a float).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, given that with rgrep float crengine/
, I only see my stuff for supporting CSS floats, I'd say crengine is fully fixed-point arithmetic ! So, not going to introduce the first float variable :)
Ok, so it will be:
unsigned int scale_w = (container_w<<16) / img_w
[...]
new_h = (img_h * scale_w) >> 16;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the overflow warnings above w/ 65536
;).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, so, let's say the max image or contained width or height we'll meet will be 65535px :)
echo $(( (2 ** 16) * (2**15) ))
2147483648
or should I use <<15
or <<14
to be safer ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh my, but in new_h = (img_h * scale_w) >> 16
, (img_h * scale_w)
will overflow.
So, I guess it should be img_h * (scale_w >> 16)
- but then I can't figure if it's useful or if the >>16 serves nothing :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, letting the 1024 as-is. I'll rethink that when I have to - or never :)
And letting it as signed int - dunno if in some edge cases, I can have negative container widths...
crengine/src/lvtinydom.cpp
Outdated
@@ -16124,11 +16124,16 @@ void ldomNode::initNodeStyle() | |||
{ | |||
ldomNode * parent = getParentNode(); | |||
|
|||
/* This has never triggered over the years, so trust we don't need it. | |||
* This might also improves quite a bit TXT documents handling (where the main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also improves or might also improve ^_^
(Upstream) HyphMan cleanup
Relevant stuff by @virxkane picked from https://github.com/virxkane/coolreader/commit/e461e58c6cc69458204852eed9225e0ad1fa0d6d
Rendering methods: remove erm_runin
Text formatting: simplify 'display: run-in' handling
Simplify it so this obsolete stuff used to support for FB2 footnotes (see #329) is more localized and does not bleed on too much code.
This also fixes an issue with alignment since #347 cleaning. Will allow closing koreader/koreader#6344.
For reference, FB2 footnotes could be handled with floats (but display: run-in has the benefit of blending in the paragraph, so for Arabic RTL FB2, they would be displayed at start, on the right - unlike with floats):
But we'll keep using
display: run-in
(with floats, they would not work in legacy and flat rendering modes)Simplify background image drawing
CSS: adds support for "background-size" property
CSS: support background:url("data:image/png;base64,...)
Some fix and improvement to CSS background images.
Will allow closing koreader/koreader#6345 (comment) .
Fix elements cancelling inherited "white-space: pre"
Will allow closing koreader/koreader#6346 (comment) .
initNodeStyle(): skip some possibly costly validation
Some optimisation, mostly only noticable with large TXT documents. See koreader/koreader#3646 (comment) .
This change is