Fonts, Style tweaks: smaller menus to see more of the book #5863
Conversation
frontend/ui/data/css_tweaks.lua
Outdated
| title = _("Indentation on first paragraph line"), | ||
| description = _("Indentation on the first line of a paragraph is the default, but it may be overridden by publisher styles. This will force KOReader's defaults on common elements."), | ||
| css = [[ | ||
| title = _("Paragraphs first line indentation"), |
There was a problem hiding this comment.
| title = _("Paragraphs first line indentation"), | |
| title = _("Paragraph first-line indentation"), |
frontend/ui/data/css_tweaks.lua
Outdated
| title = _("No spacing between paragraphs"), | ||
| description = _("No whitespace between paragraphs is the default, but it may be overridden by publisher styles. This will re-enable it for paragraphs and list items."), | ||
| css = [[p, li { margin-top: 0 !important; margin-bottom: 0 !important; }]], | ||
| title = _("Paragraphs margins and paddings"), |
There was a problem hiding this comment.
| title = _("Paragraphs margins and paddings"), | |
| title = _("Paragraph margin and padding"), |
| title = _("Paragraphs margins and paddings"), | |
| title = _("Paragraph margins and paddings"), |
| title = _("Paragraphs margins and paddings"), | |
| title = _("Paragraph spacing"), |
frontend/ui/data/css_tweaks.lua
Outdated
| title = _("Paragraphs margins and paddings"), | ||
| { | ||
| id = "margin_horizontal_most_0"; | ||
| title = _("Ignore paragraphs horizontal margins"), |
There was a problem hiding this comment.
This collection sounds a bit awkward, mainly because of the adjective order.
| title = _("Ignore paragraphs horizontal margins"), | |
| title = _("Ignore horizontal paragraph margins"), |
frontend/ui/data/css_tweaks.lua
Outdated
| }, | ||
| { | ||
| id = "margin_vertical_most_0"; | ||
| title = _("Ignore paragraphs vertical margins"), |
There was a problem hiding this comment.
| title = _("Ignore paragraphs vertical margins"), | |
| title = _("Ignore vertical paragraph margins"), |
frontend/ui/data/css_tweaks.lua
Outdated
| }, | ||
| { | ||
| id = "padding_horizontal_most_0"; | ||
| title = _("Ignore paragraphs horizontal padding"), |
There was a problem hiding this comment.
| title = _("Ignore paragraphs horizontal padding"), | |
| title = _("Ignore horizontal paragraph padding"), |
frontend/ui/data/css_tweaks.lua
Outdated
| }, | ||
| { | ||
| id = "padding_vertical_most_0"; | ||
| title = _("Ignore paragraphs vertical padding"), |
There was a problem hiding this comment.
| title = _("Ignore paragraphs vertical padding"), | |
| title = _("Ignore vertical paragraph padding"), |
|
@poire-z Btw did you want to implement #5859 (comment) or shall I? I basically just want to add those same minor adjustments to the readerdictionary styles, like this: blockquote { margin: 0 1em; } /* or maybe 0 0 0 1em */
dd { margin: 0 1em; } /* or maybe 0 0 0 1em */ |
Not really, please go at it (and I have no complex dict to check and decide which is best :) |
|
About
The 3 sub-menus in that order:
But actually, "No spacing between paragraphs" has the same CSS content as "Ignore paragraphs vertical margins". Any thoughts? |
|
It sounds the most logical to put vertical margin/padding in the existing spacing menu, and horizontal margin/padding as a submenu in the main paragraph menu. |
To fit more lines in the popup, and to look more like how crengine epub.css would render the content. Also normalize some horizontal margins.
To get more room below to see how the text looks with the selected font.
Try to limit the nb of items per menu page to 5 or 6 by splitting related ones into sub-menus, so we get more room below to see how they affect the content. Adds "No indentation on first/following paragraphs" and "Paragraphs margins and paddings", and Links underlining.
|
Simplified the TouchMenu per_page handling (we didn't really need a stack... updating a single place was enough :) As for the paragraphs tweaks, reorganized and avoiding the duplicate, that would give:
|
|
@poire-z Did you still want to change anything or ready to go? |
|
Nope, ready to go (was just waiting a bit after release in case we needed some hot fix without any new stuff - or for another first commit after release, that you just did :) |
|
I'd like to add a style tweak like this one: Any rewording suggestion, for this one and/or the existing one ? Also, I'm a bit bothered getting now 6 items in this menu (although 6 is still fine, but 5 is best for such things we want to see more of its effect without closing the menu). It wouldn't help with making it smaller, but I realize there are a few things that may be badly organized:
Any thoughts ? |
|
|
Nothing much to add to that. Moving the footnotes would probably be fine but I don't think it's necessary. Maybe a few more elements? Such as |
|
I am not quite sure, there are ignore publisher entries scattered around in the whole style tweaks menu. They are sorted into sane places. But the question is: Does the user recognise if the padding happens in a table environment or anywhere else? Is it a font or a line hight problem... Most books get rendered very well (I like it!). But if I open a misbehaving one, where do I look first? -> In the "Style tweak - Ignore publisher menu". (Because I trust KOReader ). Hhmm there is no such menu entry, so let's go through the numerous submenus until I find the right one (maybe by trial an error). So shouldn't we discuss to bundle all the "Ignore vendors" in one submenu? |
That's best left to the "Ignore publisher line-height" - and we can then use our bottom menu widget to tweak it (rather than forcing 1.5 or needing other values).
That could be a way to lay out the menu, but I don't think it would really be better:
tldr: Style tweaks is a zoo showing the diversity of CSS/HTML layout that one should enjoy and learn. It's not a mafia restaurant where you go to hire killers, that will miss their target half of the time :) You often end up needing to do the dirty work yourself :) |
|
About the idea of moving Ignore horizontal paragraph margins from it would add another kind of confusion, as some of the paragraphs vertical margins is already (rightly I think) located in Unless we consider horizontal margins an annoyance, and vertical margins a feature/style choice of paragraphs. Or instead of regrouping like on the second screenshots (section for h/v margins, section for h/v padding - the distinction between padding and margin being a bit obscure), we go with grouping by horizontal: Although sometimes, it's nice to have that padding/margin granularity as it happens using one or the other kill the unwanted margin while leaving some other wanted ones, but it's mostly luck :) But such changes would need us ro rename the tweaks' ids and may change some current users layouts... I could also duplicate (same twead id and css) some of the paragraph spacing stuff into Ignore margin stuff... Well, no real obviously less confusing ideas for now... Also, a precision to my previous post: Most of the |
What happens right now if you use |
|
crengine does not support |
|
I have reorganized a bit our style tweaks, making the main menu and others smaller: Changes:
|
Minor personal issue with this: previously, I saw Another question, regarding in-page footnotes. Is this only my personal taste ? Or is it obvious :) the second one is better (the number being enough to see a new footnote start, and easier to find when not indented) ? Another issue I have with the <aside class="ntb" epub:type="footnote" id="ftn102">
<p class="note"><a class="notesymbol" href="chapitre13.xhtml#bodyftn102">102</a> Some stuff.</p>
</aside>This construct is very common in French books. I can't/don't want to add to the existing tweak: *[type~="note"] p,
*[type~="endnote"] p,
*[type~="footnote"] p,
*[type~="rearnote"] p,
*[role~="doc-note"] p,
*[role~="doc-endnote"] p,
*[role~="doc-footnote"] p,
*[role~="doc-rearnote"] p
{
font-size: 0.8rem !important;
}as it feels these would make the CSS checks&apply a lot slower on books (checking all ancestors of all P)... Thoughts? |
I too think unindented looks better. Also it saves space, so more useful notes can fit. |
|
I'm brainbreezing (gentle brainstorming) with the idea of adding an internal CSS property/bitmap, in a way similar to the We could then have the engine set (by early inheritance of this new property) We then could use something like the following in individual style tweaks that could be "added" once a EPUB/Wikipedia/ClassicClassname has been used succesfully (instead of having to duplicate each of them with "(smaller)"). * {
-cr-only-if: inside-inpage-footnote block;
font-size: 0.8rem !important; /* only if block, keep <sup> smaller font size */
}(instead of the longer and less efficient suggestion in my previous post). And, to counteract any nested blocks (or DL/DT/DD like I've met recently) that would put the footnote number on a paragraph, and the text in another, and make everything smoothly inline * {
-cr-only-if: inside-inpage-footnote block;
display: inline !important;
}I would use "cr_hinted" as the name for this internal property - but any thought about a better name for it, that would be sufficiently different from "cr_hint" ? I found "clue" or "cue" as small synonyms, but I'm not really used to these words (or they don't sound as clear as "hint" to me). Or "colored: inside-inpage-footnote" or "scent: block" :) Thoughts? |
Do you mean they were excessively large? Having a bit of a list or a couple of paragraphs or something sounds a-okay to me and forcing them to be inline like a net negative.
I'm not sure if I quite understand the "hinted" phrasing. Isn't it more of a context? |
No, it was a bunch of: <body>
<dl class="notes">
<dt id="footnote-102" class="calibre5">[<a href="index_split_018.xhtml#citation-102" class="calibre6">102</a>
]</dt>
<dd class="calibre7" id="calibre_pb_131"><p class="p-p53">blah blah</p></dd>
</dl>
</body>which where rendered (as dt and dd are block elements) as: We can also get that kind of stuff with other contexts, like a bunch of DIV (when the publisher decides to make a new page for each footnote).
It would only be an option. Fighting the above dt dl ended me having to type/test/use: .notes { -cr-hint: footnote-inpage; margin: 0 !important;}
.notes > dt { display: inline !important; font-size: 1em !important}
.notes > dd, .notes > dd > p { display: inline !important; font-size: 1em !important}With the above solution, I would just enable these 2 tweaks, and they would work.
Yep, |
Makes sense. :-) |
|
About my above idea of using: * {
-cr-only-if: inside-inpage-footnote block;
display: inline !important;
}I had some obvious issue with CSS specificity: So, I had to add some way to increase the specificity of some selectors. So, I'll go with just |
|
So, I'm reworking the "In-page footnotes" submenu. It's a bit more logical and practical, and it allows tuning / taming down publisher footnotes look, including the one we would need to enable via a book style tweak when none of the 3 existing enabling tweak work. So, I have a super toolkit menu to tame down footnotes, but no real nice first time experience for a normal user. My updated "Inpage-footnotes" menu would be: In-page EPUB footnotesShow EPUB footnote text at the bottom of pages that contain links to them. This only works with footnotes that have specific attributes set by the publisher. *[type~="note"],
*[type~="endnote"],
*[type~="footnote"],
*[type~="rearnote"],
*[role~="doc-note"],
*[role~="doc-endnote"],
*[role~="doc-footnote"],
*[role~="doc-rearnote"]
{
-cr-only-if: -fb2-document;
-cr-hint: footnote-inpage;
margin: 0 !important;
}
In-page Wikipedia footnotesShow footnotes at the bottom of pages in Wikipedia EPUBs. ol.references > li {
-cr-hint: footnote-inpage;
list-style-position: -cr-outside;
margin: 0 !important;
}
/* hide backlinks */
ol.references > li > .noprint { display: none; }
ol.references > li > .mw-cite-backlink { display: none; }
In-page classic classname footnotesShow footnotes with classic classnames at the bottom of pages. This tweak can be duplicated as a user style tweak when books contain footnotes wrapped with other class names. .footnote, .footnotes, .fn,
.note, .note1, .note2, .note3,
.ntb, .ntb-txt, .ntb-txt-j,
.przypis, .przypis1, /* Polish footnotes */
.voetnoten /* Dutch footnotes */
{
-cr-hint: footnote-inpage;
margin: 0 !important;
}
In-page footnote font sizeFootnote font size: 100 %*, autoBoxing {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote -inline;
font-size: 1rem !important;
}
Footnote font size: 90 %*, autoBoxing {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote -inline;
font-size: 0.9rem !important;
}
Footnote font size: 85 %*, autoBoxing {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote -inline;
font-size: 0.85rem !important;
}
Footnote font size: 80 %*, autoBoxing {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote -inline;
font-size: 0.8rem !important;
}
Footnote font size: 75 %*, autoBoxing {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote -inline;
font-size: 0.75rem !important;
}
Footnote font size: 70 %*, autoBoxing {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote -inline;
font-size: 0.7rem !important;
}
Footnote font size: 65 %*, autoBoxing {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote -inline;
font-size: 0.65rem !important;
}
In-page footnote cleanupNo footnote indentation* {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote;
text-indent: 0 !important;
}
Justify footnote text* {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote;
text-align: justify !important;
}
Remove block marginsRemove block margin and padding inside inpage footnotes. * {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote -inline;
margin: 0 !important;
padding: 0 !important;
}
Remove cosmetic spacingRemove any margin and padding inside inpage footnotes, including between inline elements. * {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote;
margin: 0 !important;
padding: 0 !important;
}
Inline all footnote contentIf the footnote number is on a single line and the footnote text on the next line, or if there are variable levels of indentation, this tweak can make all the footnote content become a single paragraph. This will break any complex footnote containing quotes or lists. * {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote -inpage-footnote -inline;
display: inline !important;
}
* {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote;
list-style-position: inside;
}
Regularize text size on inline elementsIf the footnote text uses variable or absolute font sizes, line height or vertical alignments, which would make it too irregular, you can reset all of them to get a leaner text (to the expense of loosing superscripts). * {
-cr-hint: late;
-cr-only-if: inside-inpage-footnote -inpage-footnote;
font-size: inherit !important;
line-height: inherit !important;
vertical-align: inherit !important;
}
(Generated with #9261 (comment) - that I allowed myself to fix :) |
|
Pardon, what fix? I thought there were no bugs (in the final edit; the initial version was missing escaping). :-P |
|
See the github "Edited by" diff: you were iterating twice, they were duplicated stuff, and some missing ones. |
|
Ah, I wouldn't have been able to spot any difference without the diff. In my defense, I wrote it in 5-10 minutes. ;-D |
|
Or we should keep the 3 It just makes/keeps this menu quite crowded, with a bit of redundancy with the font size - although it could work: the |
|
Mostly unrelated: --- a/frontend/ui/widget/touchmenu.lua
+++ b/frontend/ui/widget/touchmenu.lua
@@ -815,16 +815,18 @@ end
function TouchMenu:onSwipe(arg, ges_ev)
local direction = BD.flipDirectionIfMirroredUILayout(ges_ev.direction)
if direction == "west" then
self:onNextPage()
elseif direction == "east" then
self:onPrevPage()
elseif direction == "north" then
self:closeMenu()
+ elseif direction == "south" then
+ self:onBack()
end
end |
|
Maybe a stupid question. The chevron points up (north ) but the swipe should go down (south )? |
Yep, a bit - but people may already get used to close it all with swipe north - and only swipe south is yet unused :) |
|
@Frenzie : any thoughts about the 3 above posts ? as it was you who introduced swipe south/north to open/close the top menu. |
Closing is significantly more important than going back. Even if you don't want to close the menu per se, it's usually significantly faster to start from scratch unless you specifically want to go just one back (which is what the arrow is for). I very explicitly decided against north to go back. As to using south to go back, seems a little weird but probably fine? |
This would be great! I set these smaller ones on by default, I mostly use them in fb2 |
Show only 5 fonts by menu page to get more room below to see how the text looks with the selected font. Not sure everybody will like that (needs to extend your thumb more to browse menu pages), but the net effect is that you see the font and don't need to close the menu as previously to appreciate how it looks, and go back re-opening that menu to test another font.
Re-organize style tweaks into more submenus to also get more room below.
Add a few styletweaks: "No indentation on first/following paragraphs" #4358 (comment), "Paragraphs margins and paddings", and Links underlining.
Popup footnotes: some CSS fixes #5859 (comment)
This change is