[Plugin] CustomCleanerPlus

[Gregg Bell]

Hey Slow, I've been experimenting with your plug-in. I seem to lose the effect of my style CSS page when I run the plugin. (All the P tags lose their indents and the Center class tags don't put the stuff in the center.) Am I doing something wrong?

[slowsmile]

Gregg...Both problems that you mention seem to involve text indent. My plugin does not alter, remove or add text indent attribute declarations in an epub or html doc. I'm also assuming here that you haven't used the tabs key for indenting your text. If you've used the tabs key in your epub or html doc to create those indents then they will automatically be removed by this plugin because the tab key should never be used in an ebook.

If you like you could post your problem doc or epub as a download link in your next post and I'll have at it look for you. Just tell me what you want done and I'll try and both assess it and fix it for you.

[slowsmile]

Gregg...Just realized something. An older version of this plugin did indeed set the default p tag to no-indent. So if your p tag style was originally set with indent as the default then it would've automatically been changed to no-indent if you are using an older version of my plugin. The current version of this plugin, which does not change p tag indent settings, is v0.3.6. Best check that.

[Gregg Bell]

My bad, Slow. I deleted that file, so unfortunately I couldn't pass it along, but I was doing all kinds of things to it last night, so who knows what happened? I do know that the backmatter images were not centered because I choice the option of getting rid of the <div> tags. Which makes sense. I don't know what I did to make the p tags lose their indent.

I probably did something weird. I was removing HTML tags and stuff to test it. Stuff I won't need to do, because Sigil is going to tell me.

Next up in my experimenting is to open an .html in Sigil and then run your plug-in.

The backmatter images (of my previous ebook covers) in my current ebooks are my main concern now. I noticed that your cleaner assigns a proportionately higher percentage to larger images. I'm thinking that's so the really small images don't get too badly stretched on really big screens. Would that be right?

What seemed best to me was to use a really big image (1800pxX2700px). Reduce the size pretty drastically in GIMP (the % size, that is) so the file isn't too big, and then manually reset your plugin % to 33%.

The images will be reduced (I did do some testing viewing on Calibre's ebook Viewer) on the smaller device screens (phones and ereaders), and they won't be stretched on the really big screens (big tablets and what have you). And in both instances, they'll take up a third of the screen.

Does this make sense, or is there a better way to go?

PS. I have v0.3.6

[slowsmile]

Gregg...

"The back matter images (of my previous ebook covers) in my current ebooks are my main concern now. I noticed that your cleaner assigns a proportionately higher percentage to larger images. I'm thinking that's so the really small images don't get too badly stretched on really big screens. Would that be right?"

Adjusting the image size after running the plugin is relatively easy. After you've run the plugin in Sigil, in Text View put the cursor to the left of the relevant image and then switch to HTML View. Within the <img> tag just change the "width" value. To increase the image size, increase the % width value and to decrease it just decrease the image width value. This allows you to easily fine tune the image size to your own liking.

In general, for images that are smaller than max screen width in pixels, this plugin will automatically preserve the aspect ratio of the image as well as preserve it's approximate size proportionate to the current screen size.

Another tip which might help. When you are judging image size in Sigil, remember that using percentage values will give a size that is completely dependant on current screen width. So after I use this plugin in Sigil, in Text View I always reduce the Sigil app window to its minimum width. This gives me a useful ballpark view of what the image might look like on a tablet.

It's also fairly accepted that any submitted full-screen image that you add should normally be larger than than the actually device screen. For an image larger than your screen size, my plugin merely reduces it's width/height to 100% of the current screen width.

You should also never add a full page image that is smaller than the max screen width/height of the current device because this can cause problems like image pixelation and blurriness due to image extrapolation. As an example of this, Kindle advises that ebook cover max-page-size images should be 1600px x 2560px as the ideal. This also applies to max-page-size ebook images. But if you've got hundreds of maxi-page-size images in your ebook, then perhaps best to reduce their size to 1200px x 800px with compression to avoid any download size penalty on your ebook profit payout as occurs with some vendors like Kindle.

[Gregg Bell]

Originally Posted by slowsmile

Gregg...

"The back matter images (of my previous ebook covers) in my current ebooks are my main concern now. I noticed that your cleaner assigns a proportionately higher percentage to larger images. I'm thinking that's so the really small images don't get too badly stretched on really big screens. Would that be right?"

Adjusting the image size after running the plugin is relatively easy. After you've run the plugin in Sigil, in Text View put the cursor to the left of the relevant image and then switch to HTML View. Within the <img> tag just change the "width" value. To increase the image size, increase the % width value and to decrease it just decrease the image width value. This allows you to easily fine tune the image size to your own liking.

Thanks very much, William. Yeah, I noticed I could do that, but I ran into what seemed unusual in that the bigger image (300X450) at the same percentage was a little smaller than the smaller image (200X300). (screenshot)

I noticed too that when I ran the plugin and did not request the serif language option, it added it anyway.

Originally Posted by slowsmile

In general, for images that are smaller than max screen width in pixels, this plugin will automatically preserve the aspect ratio of the image as well as preserve it's approximate size proportionate to the current screen size.

Another tip which might help. When you are judging image size in Sigil, remember that using percentage values will give a size that is completely dependant on current screen width. So after I use this plugin in Sigil, in Text View I always reduce the Sigil app window to its minimum width. This gives me a useful ballpark view of what the image might look like on a tablet.

By Text View do you mean "Book View"? My 9.8 Sigil only has Book and Code view. And I saw no way to find a minimum width on either.

Or perhaps the Sigil app window is something else?

Originally Posted by slowsmile

It's also fairly accepted that any submitted full-screen image that you add should normally be larger than than the actually device screen. For an image larger than your screen size, my plugin merely reduces it's width/height to 100% of the current screen width.

With my backmatter images (an author photo and book covers of my previous ebooks) I want to go nowhere near 100% of the devices' screen size. The testing that I've done so far, I thought 50% was too big.

The trick is going to be getting the right image size and the right percentage.

Originally Posted by slowsmile

You should also never add a full page image that is smaller than the max screen width/height of the current device because this can cause problems like image pixelation and blurriness due to image extrapolation. As an example of this, Kindle advises that ebook cover max-page-size images should be 1600px x 2560px as the ideal. This also applies to max-page-size ebook images. But if you've got hundreds of maxi-page-size images in your ebook, then perhaps best to reduce their size to 1200px x 800px with compression to avoid any download size penalty on your ebook profit payout as occurs with some vendors like Kindle.

Yeah, it can get expensive in a hurry.

Hey, what I've been doing is making a copy of my most recent epub and then running your plugin on the copy. Then copying and pasting the HTML info for the images into the original file. To do that, I don't need to do anything with CSS, do I?

And I'm still experimenting. I'm going to resubmit one of my ebooks to KDP with all kinds of dimensions and percentages. I have a tablet now, so I'll get a better idea of what it looks like than on just my Kindle 7 Touch ereader.

Thanks. (I'll post back.)

[slowsmile]

"I noticed too that when I ran the plugin and did not request the serif language option, it added it anyway. "

This plugin will only remove all font declarations in the CSS and replace them with default serif throughout in your epub if you chose the "Convert all ebook text and headings to serif throughout" plugin option. I've just tested this option and it seems to be working as it should. However, if you haven't explicitly declared a particular font within your text or heading style then this plugin will convert that text or heading to serif by default. The rule here, when using this plugin, is not to assume or use undeclared default styling but always explicitly declare the font(with a fallback i.e. serif or sans-serif) that you actually want to use in all instances. But on further consideration, what I might do is change that so that, rather than my plugin forcing an unwanted default font on the user's epub, it allows the plugin user to determine their own default font. So I think that I'll change that and put out an update for this soon which will be more in line with what you want as the plugin user.

"By Text View do you mean "Book View"? My 9.8 Sigil only has Book and Code view. And I saw no way to find a minimum width on either. "

Yes, Text View = Book View.

"Hey, what I've been doing is making a copy of my most recent epub and then running your plugin on the copy. Then copying and pasting the HTML info for the images into the original file. To do that, I don't need to do anything with CSS, do I?"

You shouldn't have to worry about the CSS if you do the above because I avoid using classes or styles(in the CSS) and always use inline styling for the image styling instead. So, yes, you should be able to directly copy and paste the image formatting without problems.

[slowsmile]

Upgrade: The plugin behaviour has been changed in v0.3.7:

* The plugin no longer automatically converts the epub's default text font to serif. The default font will now remain unchanged unless the "Convert all ebook text and headings to default serif throughout" dialog option is chosen. My thanks to Gregg Bell.

[Gregg Bell]

Okay. Hi Bill. I'm still experimenting. Below are some of the configurations I used for the backmatter covers in my ebook.

OOPS-A-NAVY (...15): <img alt="OopsANavy200X300" height="300" src="../Images/OopsANavy200X300.jpg" width="200"/>

DUPES-A-NAVY (...51): <img alt="DupesANavyFinal200X300" src="../Images/DupesANavyFinal200X300.jpg" style="width: 33%;height: auto;"/>

RISE OF THE ANIMAL RESCUE FEMINISTS (...19) <img alt="RiseFinal300X45095pct" src="../Images/RiseFinal300X450X95pct.jpg" style="width: 33%;height: auto;"/>

I LOVE YOU I KILL YOU (...48) <img alt="ILoveYouIKillYou300X450X95pct" height="300" src="../Images/ILoveYouIKillYou300X450X95pct.jpg" width="200"/>

BLOODY SUNRISE (...06) <img alt="BloodySunriseFinal400X600" height="600" src="../Images/BloodySunriseFinal400X600X90pct.jpg" width="400"/>

SAVING BABY (...24) <img alt="Saving-Baby_ebook400X600X90pct" src="../Images/Saving-Baby_ebook400X600X90pct.jpg" style="width: 33%;height: auto;"/>

THE FIND (...41) <img alt="TheFindNew300X450" src="../Images/TheFindNew300X450X95pct.jpg" style="width: 50%;height: auto;"/>

MAN OF GOD (...02) <img alt="ManOfGodNewFinal250X375" src="../Images/ManOfGodNewFinal250X375.jpg" style="width: 33%;height: auto;"/>

Some are conventional HTML, some are yours.

To my eye BLOODY SUNRISE and THE FIND look best.

Do you have an opinion?

I would think your HTML (as in THE FIND) would provide more flexibility with all the different devices out there.

[slowsmile]

Gregg...I would certainly agree with you that The Find and Bloody Sunrise look the best.

Another idea that you may may or may not like is to put the cover image of your current ebook on the same page as the TOC. Just put the centered cover image(approx 175px x 280px) above the TOC heading. I know a few professional formatters who use this formatting tactic which does tend to colorize and spruce up a rather dull-looking TOC page that is full of boring blue TOC links.

[Gregg Bell]

Originally Posted by slowsmile

"I noticed too that when I ran the plugin and did not request the serif language option, it added it anyway. "

This plugin will only remove all font declarations in the CSS and replace them with default serif throughout in your epub if you chose the "Convert all ebook text and headings to serif throughout" plugin option. I've just tested this option and it seems to be working as it should. However, if you haven't explicitly declared a particular font within your text or heading style then this plugin will convert that text or heading to serif by default. The rule here, when using this plugin, is not to assume or use undeclared default styling but always explicitly declare the font(with a fallback i.e. serif or sans-serif) that you actually want to use in all instances. But on further consideration, what I might do is change that so that, rather than my plugin forcing an unwanted default font on the user's epub, it allows the plugin user to determine their own default font. So I think that I'll change that and put out an update for this soon which will be more in line with what you want as the plugin user.

I have always just gone with whatever Sigil does with the font. It's not like I have a problem with Serif. I was just surprised to see it added when I didn't select that option.

All I do when I run the plugin is choose the 'Reformat ebook images using percentage screen values to help normalize smaller image sizes across all ereaders.'

But when I do that I notice that some of my <i> tags have been replaced with <span style="font-style: italic;"> tags. I did not choose that option to have them replaced. (Not that replacing them is a bad idea. Is there any advantage to using the span tags for the italics?) What I also noticed is that the <i> tags are replaced only the first time they appear in the paragraph. After that they remain <i> tags. (I'll PM you the original file and then what it was after I ran the plugin.)

I did convert the .epubs to .txt files and ran a comparison and they were identical except for one thing: your plugin closed the space on the copyright (attachment).

Originally Posted by slowsmile

"Hey, what I've been doing is making a copy of my most recent epub and then running your plugin on the copy. Then copying and pasting the HTML info for the images into the original file. To do that, I don't need to do anything with CSS, do I?"

You shouldn't have to worry about the CSS if you do the above because I avoid using classes or styles(in the CSS) and always use inline styling for the image styling instead. So, yes, you should be able to directly copy and paste the image formatting without problems.

Following up on that thought. I can just use the HTML without running the plugin, right? (I'm hesitant to use it on my published ebooks since they've already been proofread.)

And on your main plugin page you say add smallcaps after running the plugin but as far as I can tell, the plugin didn't bother my smallcaps.

And the plugin changed my asterisks. (Again, I don't know if that was a bad thing. It just got rid of a lot of non-breaking spaces.)

[slowsmile]

Update: The plugin behaviour has been changed in v0.3.8:

* The plugin no longer automatically removes html space entities -- specifically "&nbsp;" and "&160;" -- from the epub or html during cleanup. My thanks to Gregg Bell.

* Added a final success dialog which will display when the plugin has finished.

[slowsmile]

Update: Fixed a bug in v0.3.9:

* Fixed a bug where the plugin always converted <b>, <u>, <i> etc tags to their span tag equivalents. The plugin now only converts these tag entities to their span tag equivalents if the "Convert all <i>, <b>, <em, <u>, <s> and <strong> tags to span styling" dialog option is selected. My thanks to Gregg Bell.

[slowsmile]

Update: Plugin behaviour has been changed in v0.4.0:

* Removed success dialog window. Requested by Gregg Bell.

[Kiruhdu]

Hi there

Is there any way to influence the body-tag that is inserted? 3% is to much for me...