0.6.1   breaks conversion by Calibre - Page 2

jackie_w · 12-14-2012, 05:48 PM

@meme, Thanks for answering.

Re: your suggested Prefs... I seem to vaguely remember from an earlier Sigil version (5.3???) that one had to have Tidy disabled in order to guarantee avoiding those extra sgc-n css classes appearing in each html file in <style>...</style> tags (possibly with different settings in each file). I want to avoid these at all costs. Will your recommended Prefs prevent me getting into this kind of trouble?

boatat72 · 12-15-2012, 04:36 AM

Pretty Print Tidy is causing this problem.
In 32 bit with it turned off the problem occurs.
In 64 bit it is turned on by default and there is no "Preferences" button to turn it off, so this problem is never seen by 64 bit users.
In 32 bit, once you have the problem you cannot change to pretty print without first removing all nbsp.
I am with @jackie_w on avoiding sgc-n because I use code view all the time and they make life very difficult.

This is not the complete answer - see my next post - @meme has the answer

cybmole · 12-15-2012, 05:36 AM

Quote:

Originally Posted by boatat72

In 64 bit it is turned on by default and there is no "Preferences" button to turn it off...

yes there is - edit - preferences... or simply f5 - all clean source options are there

now if ( in 64 bit) I untick all cleaning options & set pretty print to OFF, & then reload your test epub - it is still OK, as before..
maybe that helps narrow things down further ?

meme · 12-15-2012, 05:58 AM

Pretty Print Tidy will not create any sgc classes. Only HTML Tidy will do that. Pretty Print Tidy will format your code to look nice AND it will try to correct common errors in the file in order to make it valid XML code.

If Clean Source is OFF, then you don't need to untick the options below as they are ignored.

To be more specific about the issue with nbsp in the file - the files are missing a DOCTYPE that describes what is in the document. You can add this in manually, or just let Pretty Print Tidy do it for you - which I recommend for most people.

Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

@cybmole - are you sure that if you set Clean Source to OFF and reload the test file that it loads without any warning at all? Since there are several files running around, to be more specific: If I open "Made with 0.6.1 Converted by Calibre.epub" with clean set to OFF, I get warnings. If I set it to Pretty Print Tidy, I don't get warnings. The same with "Sigilnbsp.epub".

boatat72 · 12-15-2012, 05:59 AM

Sorry, PICNIC

I loaded 0.6.2 on the 64 bit machine this morning but it did not overwrite the (much) earlier version already there. There were no preferences in that version.

It seems that there is no difference between the 32 and 64 bit versions.
@meme is right about the missing DOCTYPE
It looks as if calibre is removing it.

If I enable Pretty Print and tick 'Automatically clean and format HTML Source code' on 'Open' everything works as expected. No errors and lots of nbsp's

My problem seems to be sorted.
Thank you everyone who got involved.

cybmole · 12-15-2012, 07:33 AM

that is good news - now, re the empty paragraphs problem I posted earlier in the thread, which got a bit overlooked...

My issue was that I was opening a book and "pretty print?" was adding empty paragraphs in between every paragraph of the book. I would remove them all, save, reload and they'd be back. Cleaning and saving with the clean options all disabled eventually got rid of them

I am guessing there were spurious invisible characters like CR or LF in the html files, which were still there after I deleted all the empty paragraphs, and so they were being neatly placed inside new tags at each load or at each save?

I have not seen this with any other books though, but maybe there needs to be something in the pretty print code to prevent the creation of empty paragraphs. They had no visual impact in book view or in reader but its bugs me that they were being put there at all

boatat72 · 12-15-2012, 08:45 AM

@cybmole Sorry, I have never seen empty paragraphs, except those created with nbsp, so I just find and replace them with nothing.

@jackie_w If you do want empty paragraphs it might be safer to add <br /><br /> to the end of the preceding paragraph, or style it

p.gap {
margin-bottom: 0.8em;
margin-top: 0em;
margin-left: 0em;
margin-right: 0em;
border: 0pt;
text-indent: 1.5em; (or whatever indent you use)
}

re the 'Sony not displaying some entities'. Do you have a universal panacea or must your solutions be applied to a specific machine?

crutledge · 12-15-2012, 02:19 PM

Quote:

Originally Posted by boatat72

Removing all   cures this completely but I find them useful for indenting the occasional line in a poem or other minor positional adjustments.
This did not happen in 0.6.0

You might try something like this in the CSS

Code:

.i0_5{
margin-left:0.5em;
}

.i1{
margin-left:1em;
}

.i2{
margin-left:2em;
}

.i4{
margin-left:4em;
}

.i6{
margin-left:6em;
}

jackie_w · 12-15-2012, 05:09 PM

Quote:

Originally Posted by boatat72

@jackie_w If you do want empty paragraphs it might be safer to add <br /><br /> to the end of the preceding paragraph, or style it

Thanks, but for my own creations I never use empty paragraphs. I use a css class with a large margin-top. The empty paragraphs I encounter are always in epubs created by others.

Quote:

Originally Posted by boatat72

re the 'Sony not displaying some entities'. Do you have a universal panacea or must your solutions be applied to a specific machine?

I'm not sure which Sony model you have. A universal panacea would be to embed better font(s) in each epub, which I think you can do in Sigil. However, I don't do this. The best solution for Sony PRS-505/300/600/x50 is to install the PRSPlus custom firmware which will let you store your chosen fonts and a set of css files on the Sony which can (usually) be used to override some of the body css inside each epub (font families, font-size, page margins, line-height, widows/orphans). Changing fonts whilst reading an epub then becomes as simple as selecting from a list.
On a Sony PRST1 a similar thing can be achieved by installing Morkl's modified reader app. I don't think the Sony PRS-T2 has anything equivalent, but all the T2's default fonts are much better than on the earlier Sony models. If you want to pursue any of these options feel free to PM me.

@cybmole,
That's a weird one. I have not experienced empty paragraphs springing into life from nowhere - not that I'm doubting what you say. The one's I've seen, to date, were certainly in the original epub before loading into Sigil.

jackie_w · 12-15-2012, 05:42 PM

Quote:

Originally Posted by meme

Pretty Print Tidy will not create any sgc classes. Only HTML Tidy will do that. Pretty Print Tidy will format your code to look nice AND it will try to correct common errors in the file in order to make it valid XML code.

Thanks for this info, meme. I can confirm that because of my concern about those wretched sgc-n classes I had originally set Clean Source to OFF. Now I've set it to 'Pretty Print Tidy' all seems well. Self-inflicted problem. D'oh

Quote:

Originally Posted by meme

To be more specific about the issue with nbsp in the file - the files are missing a DOCTYPE that describes what is in the document. You can add this in manually, or just let Pretty Print Tidy do it for you - which I recommend for most people.

Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

It looks as if a calibre import/conversion (html-->zip-->epub) doesn't add an xhtml doctype statement at any stage, which surprises me a little. Though, I can't say I've ever had a problem reading a calibre-converted epub on any of my readers. calibre's headers start like this:

Code:

<?xml version='1.0' encoding='utf-8'?>
<html xmlns="http://www.w3.org/1999/xhtml">

Something else I noticed about nbsp/calibre/Sigil is that calibre always changes the   entity to the single unicode char during the html-->zip import process, but Sigil changes it back to an entity again. I did wonder whether calibre did this because some readers couldn't handle the entity, but the Sigil edited epub seems to be OK on the Sony PRS350 and the KoboGlo I tried last night.

boatat72 · 12-16-2012, 06:20 AM

@crutledge
Thank you. I spent some time experimenting with margin-left. It works very well for epub, but not in mobi. The Kindle only understands whole ems and text-indent, any margin-left or percentage changes give just one, fixed, space. text-indent also makes the space much bigger than you would expect. When I create more than 3 indents, if the enclosing div is styled, the forth and eighth lines sometimes, but not always, get converted to the em of the line above. I have not yet found out why.
The opposite is true for font-size in mobi. It does understand part ems but the difference is much smaller than you would expect.

@ jackie_w
Thank you also. I had not heard of PRSPlus. I will give it a try on my PRS-350 and also try embedding a font.

crutledge · 12-16-2012, 09:12 AM

Quote:

Originally Posted by boatat72

@crutledge
Thank you. I spent some time experimenting with margin-left. It works very well for epub, but not in mobi. The Kindle only understands whole ems and text-indent, any margin-left or percentage changes give just one, fixed, space. text-indent also makes the space much bigger than you would expect. When I create more than 3 indents, if the enclosing div is styled, the forth and eighth lines sometimes, but not always, get converted to the em of the line above. I have not yet found out why.
The opposite is true for font-size in mobi. It does understand part ems but the difference is much smaller than you would expect.

@ jackie_w
Thank you also. I had not heard of PRSPlus. I will give it a try on my PRS-350 and also try embedding a font.

You'd best check how you are using them. They work fine for me in ePub, MOBI, and lrf.

Code:

<div class="i2">......</div>

boatat72 · 12-17-2012, 06:51 AM

@crutledge

I've had another good look at the file I made to test all these scenarios and still get the Kindle not recognising part ems for spacing. It also still gives inconsistent results for whole ems.
If you have the time I would be grateful if you (or anyone else) could look at the attached and see if it's my fault.

The problem of part ems not working in the attached files have been solved by @crutledge. See my next post.

cybmole · 12-17-2012, 09:27 AM

from memory - from when I last had a Kiindle

1. it did not do fractions of ems, only whole numbers
2. it could not split a line around a—emdash character, resulting in some strange looking lines. I concluded that endash with spaces either side was more practical.

( just 2 of the reasons why I now use Sony readers instead ! )

maybe later Kindle firmware is better - you could ask on kindle forum- or look for firmware upgrade release notes

crutledge · 12-18-2012, 09:18 AM

Quote:

Originally Posted by boatat72

@crutledge

I've had another good look at the file I made to test all these scenarios and still get the Kindle not recognising part ems for spacing. It also still gives inconsistent results for whole ems.
If you have the time I would be grateful if you (or anyone else) could look at the attached and see if it's my fault.

I'm no expert on CSS.
The following works for me in ePub, MOBI, and LRF.

Code:

.i2{
margin-left:2em;
}
.i4{
margin-left:4em;
}
.poem {
margin-bottom:1em;
margin-top:1em;
margin-left:5em;
margin-right:0;
}
.stanza {
text-indent:0;
}

Code:

  <div class="poem">
    <div class="stanza">
      <span class="i2">>"Shall a man prefer the darkness of night to the glories of risen day?</span><br />
      <span class="i4">Or shall a man turn from the lilies to pluck the lowly flower of the field?"</span>
    </div>
  </div>

12-15-2012, 04:36 AM	#17
boatat72 Member Posts: 19 Karma: 10 Join Date: Apr 2011 Location: Cambridge UK Device: Kindle, Sony Reader, iPad, Kobo, Nook	Pretty Print Tidy is causing this problem. In 32 bit with it turned off the problem occurs. In 64 bit it is turned on by default and there is no "Preferences" button to turn it off, so this problem is never seen by 64 bit users. In 32 bit, once you have the problem you cannot change to pretty print without first removing all nbsp. I am with @jackie_w on avoiding sgc-n because I use code view all the time and they make life very difficult. This is not the complete answer - see my next post - @meme has the answer Last edited by boatat72; 12-18-2012 at 12:33 PM. Reason: further information

12-15-2012, 05:58 AM	#19
meme Sigil developer Posts: 1,275 Karma: 1101600 Join Date: Jan 2011 Location: UK Device: Kindle PW, K4 NT, K3, Kobo Touch	Pretty Print Tidy will not create any sgc classes. Only HTML Tidy will do that. Pretty Print Tidy will format your code to look nice AND it will try to correct common errors in the file in order to make it valid XML code. If Clean Source is OFF, then you don't need to untick the options below as they are ignored. To be more specific about the issue with nbsp in the file - the files are missing a DOCTYPE that describes what is in the document. You can add this in manually, or just let Pretty Print Tidy do it for you - which I recommend for most people. Code: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> @cybmole - are you sure that if you set Clean Source to OFF and reload the test file that it loads without any warning at all? Since there are several files running around, to be more specific: If I open "Made with 0.6.1 Converted by Calibre.epub" with clean set to OFF, I get warnings. If I set it to Pretty Print Tidy, I don't get warnings. The same with "Sigilnbsp.epub".

12-15-2012, 05:59 AM	#20
boatat72 Member Posts: 19 Karma: 10 Join Date: Apr 2011 Location: Cambridge UK Device: Kindle, Sony Reader, iPad, Kobo, Nook	Sorry, PICNIC I loaded 0.6.2 on the 64 bit machine this morning but it did not overwrite the (much) earlier version already there. There were no preferences in that version. It seems that there is no difference between the 32 and 64 bit versions. @meme is right about the missing DOCTYPE It looks as if calibre is removing it. If I enable Pretty Print and tick 'Automatically clean and format HTML Source code' on 'Open' everything works as expected. No errors and lots of nbsp's My problem seems to be sorted. Thank you everyone who got involved. Last edited by boatat72; 12-15-2012 at 06:52 AM. Reason: re-testing with 0.6.2

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Use of nonbreaking space ( )	Ti-Ron	ePub	10	04-14-2013 10:57 PM
Use of   for spacing	Ripplinger	Sigil	11	11-25-2012 04:36 AM
iBooks does NOT LIKE	Erin	Apple Devices	0	09-13-2011 11:17 AM
Specify indent in css, not with &nbsp	James_Wilde	Calibre	7	09-13-2010 09:48 PM
Mobiperl   lost when converting to mobi	Jellby	Kindle Formats	19	08-26-2008 03:10 PM

12-14-2012, 05:48 PM	#16
jackie_w Grand Sorcerer Posts: 6,212 Karma: 16534894 Join Date: Sep 2009 Location: UK Device: Kobo: KA1, ClaraHD, Forma, Libra2, Clara2E. PocketBook: TouchHD3	@meme, Thanks for answering. Re: your suggested Prefs... I seem to vaguely remember from an earlier Sigil version (5.3???) that one had to have Tidy disabled in order to guarantee avoiding those extra sgc-n css classes appearing in each html file in <style>...</style> tags (possibly with different settings in each file). I want to avoid these at all costs. Will your recommended Prefs prevent me getting into this kind of trouble?

12-15-2012, 07:33 AM	#21
cybmole Wizard Posts: 3,720 Karma: 1759970 Join Date: Sep 2010 Device: none	that is good news - now, re the empty paragraphs problem I posted earlier in the thread, which got a bit overlooked... My issue was that I was opening a book and "pretty print?" was adding empty paragraphs in between every paragraph of the book. I would remove them all, save, reload and they'd be back. Cleaning and saving with the clean options all disabled eventually got rid of them I am guessing there were spurious invisible characters like CR or LF in the html files, which were still there after I deleted all the empty paragraphs, and so they were being neatly placed inside new tags at each load or at each save? I have not seen this with any other books though, but maybe there needs to be something in the pretty print code to prevent the creation of empty paragraphs. They had no visual impact in book view or in reader but its bugs me that they were being put there at all

12-15-2012, 08:45 AM	#22
boatat72 Member Posts: 19 Karma: 10 Join Date: Apr 2011 Location: Cambridge UK Device: Kindle, Sony Reader, iPad, Kobo, Nook	@cybmole Sorry, I have never seen empty paragraphs, except those created with nbsp, so I just find and replace them with nothing. @jackie_w If you do want empty paragraphs it might be safer to add <br /><br /> to the end of the preceding paragraph, or style it p.gap { margin-bottom: 0.8em; margin-top: 0em; margin-left: 0em; margin-right: 0em; border: 0pt; text-indent: 1.5em; (or whatever indent you use) } re the 'Sony not displaying some entities'. Do you have a universal panacea or must your solutions be applied to a specific machine?

12-16-2012, 06:20 AM	#26
boatat72 Member Posts: 19 Karma: 10 Join Date: Apr 2011 Location: Cambridge UK Device: Kindle, Sony Reader, iPad, Kobo, Nook	@crutledge Thank you. I spent some time experimenting with margin-left. It works very well for epub, but not in mobi. The Kindle only understands whole ems and text-indent, any margin-left or percentage changes give just one, fixed, space. text-indent also makes the space much bigger than you would expect. When I create more than 3 indents, if the enclosing div is styled, the forth and eighth lines sometimes, but not always, get converted to the em of the line above. I have not yet found out why. The opposite is true for font-size in mobi. It does understand part ems but the difference is much smaller than you would expect. @ jackie_w Thank you also. I had not heard of PRSPlus. I will give it a try on my PRS-350 and also try embedding a font.

12-17-2012, 09:27 AM	#29
cybmole Wizard Posts: 3,720 Karma: 1759970 Join Date: Sep 2010 Device: none	from memory - from when I last had a Kiindle 1. it did not do fractions of ems, only whole numbers 2. it could not split a line around a—emdash character, resulting in some strange looking lines. I concluded that endash with spaces either side was more practical. ( just 2 of the reasons why I now use Sony readers instead ! ) maybe later Kindle firmware is better - you could ask on kindle forum- or look for firmware upgrade release notes