06-21-2011, 12:41 PM | #136 |
Wizard
Posts: 1,337
Karma: 123455
Join Date: Apr 2009
Location: Malaysia
Device: PRS-650, iPhone
|
Question on capnm's '#cover @page' example. I know that using an id before a selector is kosher in general, but how can it be kosher to apply an id to @page? That selector is a pseudo selector referring to the devices page boundaries - it's never actually defined in the html code, so I don't see how an id can be associated with it.
I'm asking because I'm thinking about how to check whether @page is defined, and an @page with an id is problematic - if it's invalid syntax then it can be deleted/ignored. |
06-21-2011, 01:22 PM | #137 |
Groupie
Posts: 156
Karma: 10001
Join Date: Feb 2011
Device: sony
|
Are you trying to do too much?
As of now this will strip 'book level' margins from >99% of commercially published epubs. And those are the most annoying ones. It will potentially screw up the formatting of Calibre generated epubs, and a variety of bespoke epubs. Calibre generated epubs should be pretty good candidates for epub-epub conversion by Calibre. Some bespoke epubs really need to be be adjusted by hand, or not at all. |
Advert | |
|
06-21-2011, 01:59 PM | #138 |
Wizard
Posts: 1,337
Karma: 123455
Join Date: Apr 2009
Location: Malaysia
Device: PRS-650, iPhone
|
I was leaning toward not trying too hard . I'm going to ignore the @page with an ID problem and leave that as a case that someone would need to fix by hand - though margins will still be removed in that case, they just wouldn't be added back based on the Calibre pref.
The question was also partially academic - if there is some way an ID can be assigned to a pseudo selector like @page I was curious to know about it. edit: The rest of the work comes out of integration with Quality check, and providing users a simple way to fix ADE page number rendering. You're correct that newer ADE renderers don't display the numbers - my 650 doesn't display them. But any users of older devices will still be affected, so I figured the extra effort wouldn't be unappreciated. Last edited by ldolse; 06-21-2011 at 02:02 PM. |
06-21-2011, 04:19 PM | #139 |
calibre/Sigil Developer
Posts: 4,601
Karma: 2092290
Join Date: Oct 2010
Location: Australia
Device: Kindle Oasis
|
v0.3.4 Beta
Changes in this release:
This version includes Idolse's work on the page/body margins stuff, which I believe now reads your Calibre preferences for page margins and then adds them into the CSS stylesheet. As it stands currently this code only looks at the CSS files for .body/@page directives - any that are specified inline in the HTML page are not considered. Investigation still ongoing for the latter. @Idolse - as mentioned above I have (for now at least) made this a separate option within the dialog. We may decide to roll them back together in future but at least this way people can test in isolation. |
06-21-2011, 04:52 PM | #140 |
Chasing Butterflies
Posts: 3,132
Karma: 5074169
Join Date: Mar 2011
Location: American Southwest
Device: Uses batteries.
|
I'm totally trying that out.
One thing, though, is it rewriting the margins to not exist at all, or did you go with the "5px let, 10px right", or.......? |
Advert | |
|
06-21-2011, 05:06 PM | #141 |
Groupie
Posts: 156
Karma: 10001
Join Date: Feb 2011
Device: sony
|
Let me talk my way through this ....
As it is -- The strip margins function will strip out any margins in @page or body statements in all css files. This should be pretty darn safe. I don't think it will touch files created by any versions of Calibre to date. (They don't use body, and they don't use @page in the css). The only potential problems I can think of occur when there are multiple @page statements, either named or in multiple stylesheets. Then, in very rare cases it could cause minor damage: 1) I've seen a couple of bespoke epubs that include an extra css specifically to facilitate conversions to pdf using Prince. 2) You might lose features such as extra whitespace at top of a title page. 3) It could mess up an epub that used body statements in the css and @page statements in the html, but nobody's doing that. Yet. Adding margins to epubs, after successfully stripping the old ones should be pretty straightforward -- just inject an @page at the beginning of (each) css. That should (might?) work even if there are still additional @page statements for non-margin purposes (and it's very rare that there would ever be). Stripping margins from Calibre generated epubs is more complex, leaving much more room for error, as different versions used different techniques to define them. Likewise adding margins to Calibre generated epubs isn't going to work well unless you've successfully stripped them. Stripping the @page statements from the html files (required to strip margins from epubs recently created by Calibre) seems to be asking for trouble. It would be nice to tag css files where you've stripped (and possibly added) margins so you know they're fair game for adding margins to, and that they can be ignored when looking for files to strip the margins from. I'm already contemplating complicating Quality Check 1) Find epubs with strippable margins (other than those generated by Modify Epub) 2) Find epubs with strippable or already stripped margins ( knowing that Modify Epub could then (re)set those margins) As an aside: That could well be invalid code. I found it while looking for either @page pseudo-class (@page :first {}) or @page nameid {} statements -- which I think are correct syntax, but I didn't find any examples of them in my library. As another aside: I'd be curious to hear what Kovid would have to say about possibly eventually switching Calibre to the @page/body in css syntax. I suspect he has some pretty good reasons for doing it the way it is. Last edited by capnm; 06-21-2011 at 05:08 PM. |
06-21-2011, 05:15 PM | #142 |
calibre/Sigil Developer
Posts: 4,601
Karma: 2092290
Join Date: Oct 2010
Location: Australia
Device: Kindle Oasis
|
I believe it uses your Calibe page setup defaults, so the same as would be applied if you did a conversion. However I defer all detailed support questions on this feature to Idolse as it is his baby
|
06-21-2011, 05:44 PM | #143 | |
Resident Curmudgeon
Posts: 73,660
Karma: 127838196
Join Date: Nov 2006
Location: Roslindale, Massachusetts
Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3
|
Quote:
I put the margins in body and I fix them where they are also written differently. There a bug in Calibre you'll need to code for.. in each XML Calibre writes, it adds a style to the XML that has a 5pt top and bottom margin. Those have to go. |
|
06-21-2011, 09:23 PM | #144 |
Wizard
Posts: 1,337
Karma: 123455
Join Date: Apr 2009
Location: Malaysia
Device: PRS-650, iPhone
|
Calibre's preferences are hard-coded to pts.
If you want no margins in @page or body, then set your calibre preferences under 'page setup' in common conversion options to have all the margins zero - this will cause the plugin to work exactly as the initial implementation I posted did - any margins in @page or body will simply be deleted. Otherwise, the plugin will delete all existing margins in body or @page, and then replaces them with the pt based margins specified in Calbre's preferences. It only puts the new margin settings in @page, so all margins set on body are always removed. Capnm is correct in the extremely rare case that the epub css has multiple @page statements, some using 'ID', they will all be re-written, but any using an ID will just have them removed. I'm actually inclined to think that @page statements with an ID is invalid css anyway, but we'll see if someone else can provide some further enlightenment on that point. @page statements using a psuedo selector like :first would actually be ignored. @JSWolf, I chose to put them in @page because this is the advice I've read from epub guru's like pdurrant, Kovid, and Jelby. I believe @page is more focused on device page boundaries vs. the entire text, which is what body will do. I would have liked to be able to research it more, but try googling @page - big fail. Removing the xpgt file entirely is a bit outside of the scope of this plugin, as it's focused on non/minimally-destructive changes. As Jelby has pointed out in the epub sub-forum, there are some potentially good uses for it, such as detecting whether ADE is the renderer and creating some work-around css styles that only it will render. Edit - one last point I didn't see - if you don't like Calibre specifying top and bottom margins, simply set those to zero under page setup. That should eliminate them during conversions and with this plugin. Last edited by ldolse; 06-21-2011 at 09:53 PM. |
06-21-2011, 09:33 PM | #145 |
Wizard
Posts: 1,337
Karma: 123455
Join Date: Apr 2009
Location: Malaysia
Device: PRS-650, iPhone
|
Regarding capnm's Quality Check comment - that's my next target. The initial problem was allowing user configurable margins that could both be rewritten AND excluded from a Quality Check search. Using Calibre's prefs allows a common place to store this for both plugins.
So Quality check will get a new check which searches out all epubs which don't have margins agreeing with Calibre's configured preferences. Not sure if I'll get to that today, but that's my next focus aside from fixing any bugs I may have just introduced with these changes. |
06-22-2011, 03:09 AM | #146 | |
Guru
Posts: 776
Karma: 2751519
Join Date: Jul 2010
Location: UK
Device: PW2, Nexus7
|
Quote:
For example, set margin-top:10px in @PAGE and there will always be a 10 pixel margin at the top of the physical page - which can be useful to avoid shadow casting from the reader's bezel. This margin is preserved as you move forward through the xhtml file. However, setting margin-top:10px in BODY will only achieve 10px at the start of the xhtml page. Once you move forward through the xhtml file there will be no 10px gap at the top of the reader's screen. |
|
06-22-2011, 08:22 AM | #147 |
Grand Sorcerer
Posts: 6,171
Karma: 16228536
Join Date: Sep 2009
Location: UK
Device: Kobo: KA1, ClaraHD, Forma, Libra2, Clara2E. PocketBook: TouchHD3
|
Does anyone know why current Calibre conversions choose to put the @page top/bottom margins inside each and every xhtml file, rather than just once in the css?
As it would appear to be more effort, I'm assuming there must be a good reason to do it this way. |
06-22-2011, 09:23 AM | #148 |
Guru
Posts: 776
Karma: 2751519
Join Date: Jul 2010
Location: UK
Device: PW2, Nexus7
|
No idea! I use Tweak ePub and remove them all. A single @page in the main CSS is sufficient. I suppose using them at the xhtml file level would allow you to vary margins at this level - but this would also require a post-conversion tweak.
|
06-22-2011, 09:36 AM | #149 |
Groupie
Posts: 156
Karma: 10001
Join Date: Feb 2011
Device: sony
|
Another inquiring mind would love to know
It looks to me suspiciously like a work-around. It could provide the functionality of named @pages even if 'proper' named @page syntax wasn't being rendered correctly. |
06-22-2011, 10:24 AM | #150 | |
Groupie
Posts: 156
Karma: 10001
Join Date: Feb 2011
Device: sony
|
Quote:
Here's my logic *cough* .... I'd like to search for epubs with @page and/or body margins -- those being 'good' candidates for this mod. That eliminates all the Calibre conversions and many bespoke epubs, with which this doesn't play nicely. But if I set the margins to 0, and the margins are all deleted, I will no longer recognize those epubs as being good candidates for resetting margins. I think I might be overlooking a simpler approach |
|
Thread Tools | Search this Thread |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Any web-to-epub plugin for internet browser? | bthoven | ePub | 7 | 07-10-2011 05:14 AM |
[Old Thread] Reading epub on viewer inexplicably changes the time stamp of epub | greenapple | Library Management | 20 | 03-19-2011 10:18 PM |
Easy way to modify thread subscription emails in bulk? | snipenekkid | Feedback | 11 | 02-06-2011 03:47 AM |
Another plugin dev question | DiapDealer | Plugins | 2 | 12-11-2010 01:46 PM |
Epub plugin dev | DiapDealer | Plugins | 15 | 11-12-2010 09:36 AM |