instead of  

Alt68er · 12-29-2013, 04:55 AM

Hi all,

I'm new here and therefore ask you to excuse me if I'm making wrong something...

Yesterday I updated Sigil from 0.7.3 to 0.7.4 and then continued "my work" with a series of existing epubs, i.e. editing them to give them an identical look and feel.

During the first editing which also included to replace the existing stylesheet with my own, adding 2 new chapters (cover and introduction) and then splitting the existing complete file into chapters I suddenly saw that Sigil in one chapter had replaced all existing nbsp by #160 automatically and I don't know how to stop that automatism.

I don't want to have #160 in my books instead of nbsp because I already "converted" about 300 which contain nbsp and I want that the remaining 2000 also will have nbsp.

I sincerely hope that someone here knows what I mean and also how I can stop it.

So, please please, tell me !!

1000 thanks in advance and a nice Sunday,
Peter

At_Libitum · 12-29-2013, 07:02 AM

they're one and the same thing. One is the html entity and the other the codepoint for that character. I have read this was done for a reason although I cannot remember which (CRAFT). But if it wasn't something critical it wouldn't have gotten changed.

mrmikel · 12-29-2013, 07:06 AM

Beat by Ad Libitum....Curses, foiled again!

Jellby · 12-29-2013, 07:42 AM

Try adding a correct DOCTYPE to the document.

DiapDealer · 12-29-2013, 07:46 AM

The only way you could "stop" this is to go back o 0.7.3 (and make sure all docs that contain nbsp have the proper doctype declaration). There no real differences between 0.7.3 and 0.7.4 otherwise (on Windows).

You can't change the behavior in 0.7.4 (and as others have said, both entities do the same thing). It was changed because it was the easiest way around an issue where non-breaking space unicode characters were being changed (to appease Qt) to nbsp entities in documents where there was no proper DTD to support named entities: hence the numeric entity which achieves the same thing with no need for a DTD.

mrmikel · 12-29-2013, 09:32 AM

The reader of your book will see the same thing regardless of which is used.

The only case where I can conceive of this causing a problem is in an academic setting where you are told to use nbsp.

2000 non breaking spaces seems like a lot. Make sure they are used only where they are actually needed to make sure the space is

1. Never deleted by the reading program or device.
2. Two words must be jointed together.

If you are using them to generate vertical space, it is more easily and predictably done in CSS using margin-top or something similar.

Alt68er · 12-29-2013, 11:28 AM

Thanks a lot for your replies!

So, ok I'll accept the #160 in the remaining 2000 books (NOT nbsp's!).-

But - as I'm not an expert - tell me, please, what is the correct DOCTYPE for which kind of document?

Again thank you all!

Peter

Notjohn · 01-02-2014, 10:35 AM

Quote:

Originally Posted by Alt68er

But - as I'm not an expert - tell me, please, what is the correct DOCTYPE for which kind of document?

I'd like to know that, too!

One of the things I liked about Sigil was that it seemed to add a suitable doctype declaration at the top of the html without my having to specify one.

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

Is this not a good idea?

Toxaris · 01-02-2014, 11:19 AM

The DOCTYPE Sigil adds is the correct one.

DiapDealer · 01-02-2014, 11:28 AM

But you have to ALLOW Sigil to add the proper doctype if it's missing. That won't happen if you turn off all the clean-source settings.

DaleDe · 01-02-2014, 11:41 AM

I think this is a fine idea but you can't necessarily depend on all eBook readers to properly understand all of the entity names although numbers will generally work ok. The five XML names will likely work everywhere. Of course it is also possible to define your own.

Dale

Toxaris · 01-02-2014, 12:22 PM

Dale, I never heard of a reader that ignored the DOCTYPE reference causing the named entities not to work.

DaleDe · 01-02-2014, 01:46 PM

Quote:

Originally Posted by Toxaris

Dale, I never heard of a reader that ignored the DOCTYPE reference causing the named entities not to work.

You misunderstood what I said. I did not say the above. I said that in spite of defining a DOCTYPE some readers may not understand all of the named entities. This also applies to some older browsers. There is no reference to DOCTYPE causing this behavior.

Dale

Toxaris · 01-02-2014, 01:55 PM

But if the DOCTYPE is not ignored, the browser/reader must be able to understand the entities, since they are part of the DOCTYPE. It might be that the corresponding character is not in the readers font, but that is another issue of course.

DaleDe · 01-02-2014, 02:07 PM

Quote:

Originally Posted by Toxaris

But if the DOCTYPE is not ignored, the browser/reader must be able to understand the entities, since they are part of the DOCTYPE. It might be that the corresponding character is not in the readers font, but that is another issue of course.

Even if it was ignored it would not be the DOCTYPE that caused the problem. DOCTYPE needn't actually reference the actual DTD by a URL reference. DOCTYPE can reference other file types that HTML and some may recognize some but not all. I did not mean to introduce confusion here. Numbers will always work so long as the font is there in the right place.

12-29-2013, 07:02 AM	#2
At_Libitum Addict Posts: 265 Karma: 724240 Join Date: Aug 2013 Device: KyBook	they're one and the same thing. One is the html entity and the other the codepoint for that character. I have read this was done for a reason although I cannot remember which (CRAFT). But if it wasn't something critical it wouldn't have gotten changed. Last edited by At_Libitum; 12-29-2013 at 07:05 AM.

12-29-2013, 07:46 AM	#5
DiapDealer Grand Sorcerer Posts: 27,551 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	The only way you could "stop" this is to go back o 0.7.3 (and make sure all docs that contain nbsp have the proper doctype declaration). There no real differences between 0.7.3 and 0.7.4 otherwise (on Windows). You can't change the behavior in 0.7.4 (and as others have said, both entities do the same thing). It was changed because it was the easiest way around an issue where non-breaking space unicode characters were being changed (to appease Qt) to nbsp entities in documents where there was no proper DTD to support named entities: hence the numeric entity which achieves the same thing with no need for a DTD. Last edited by DiapDealer; 12-29-2013 at 09:33 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
nbsp disappeared	roger64	Sigil	55	12-22-2013 07:41 PM
Sell Kindle Fire HD 8.9 - $160	Nate the great	Flea Market	2	12-06-2013 10:38 AM
txt to Epub - nbsp nbsp	cybmole	Calibre	1	09-17-2010 09:05 AM

12-29-2013, 04:55 AM	#1
Alt68er Member Posts: 20 Karma: 10 Join Date: Dec 2013 Device: Pocketbook touch lux (623)	instead of   Hi all, I'm new here and therefore ask you to excuse me if I'm making wrong something... Yesterday I updated Sigil from 0.7.3 to 0.7.4 and then continued "my work" with a series of existing epubs, i.e. editing them to give them an identical look and feel. During the first editing which also included to replace the existing stylesheet with my own, adding 2 new chapters (cover and introduction) and then splitting the existing complete file into chapters I suddenly saw that Sigil in one chapter had replaced all existing nbsp by #160 automatically and I don't know how to stop that automatism. I don't want to have #160 in my books instead of nbsp because I already "converted" about 300 which contain nbsp and I want that the remaining 2000 also will have nbsp. I sincerely hope that someone here knows what I mean and also how I can stop it. So, please please, tell me !! 1000 thanks in advance and a nice Sunday, Peter Last edited by Jellby; 12-29-2013 at 06:01 AM. Reason: Trying to format the title :D

12-29-2013, 07:06 AM	#3
mrmikel Color me gone Posts: 2,089 Karma: 1445295 Join Date: Apr 2008 Location: Central Oregon Coast Device: PRS-300	Beat by Ad Libitum....Curses, foiled again!

12-29-2013, 07:42 AM	#4
Jellby frumious Bandersnatch Posts: 7,516 Karma: 18512745 Join Date: Jan 2008 Location: Spaniard in Sweden Device: Cybook Orizon, Kobo Aura	Try adding a correct DOCTYPE to the document.

12-29-2013, 09:32 AM	#6
mrmikel Color me gone Posts: 2,089 Karma: 1445295 Join Date: Apr 2008 Location: Central Oregon Coast Device: PRS-300	The reader of your book will see the same thing regardless of which is used. The only case where I can conceive of this causing a problem is in an academic setting where you are told to use nbsp. 2000 non breaking spaces seems like a lot. Make sure they are used only where they are actually needed to make sure the space is 1. Never deleted by the reading program or device. 2. Two words must be jointed together. If you are using them to generate vertical space, it is more easily and predictably done in CSS using margin-top or something similar.

12-29-2013, 11:28 AM	#7
Alt68er Member Posts: 20 Karma: 10 Join Date: Dec 2013 Device: Pocketbook touch lux (623)	Thanks a lot for your replies! So, ok I'll accept the #160 in the remaining 2000 books (NOT nbsp's!).- But - as I'm not an expert - tell me, please, what is the correct DOCTYPE for which kind of document? Again thank you all! Peter

01-02-2014, 11:19 AM	#9
Toxaris Wizard Posts: 4,520 Karma: 121692313 Join Date: Oct 2009 Location: Heemskerk, NL Device: PRS-T1, Kobo Touch, Kobo Aura	The DOCTYPE Sigil adds is the correct one.

01-02-2014, 11:28 AM	#10
DiapDealer Grand Sorcerer Posts: 27,551 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	But you have to ALLOW Sigil to add the proper doctype if it's missing. That won't happen if you turn off all the clean-source settings.

01-02-2014, 11:41 AM	#11
DaleDe Grand Sorcerer Posts: 11,470 Karma: 13095790 Join Date: Aug 2007 Location: Grass Valley, CA Device: EB 1150, EZ Reader, Literati, iPad 2 & Air 2, iPhone 7	I think this is a fine idea but you can't necessarily depend on all eBook readers to properly understand all of the entity names although numbers will generally work ok. The five XML names will likely work everywhere. Of course it is also possible to define your own. Dale

01-02-2014, 12:22 PM	#12
Toxaris Wizard Posts: 4,520 Karma: 121692313 Join Date: Oct 2009 Location: Heemskerk, NL Device: PRS-T1, Kobo Touch, Kobo Aura	Dale, I never heard of a reader that ignored the DOCTYPE reference causing the named entities not to work.

01-02-2014, 01:55 PM	#14
Toxaris Wizard Posts: 4,520 Karma: 121692313 Join Date: Oct 2009 Location: Heemskerk, NL Device: PRS-T1, Kobo Touch, Kobo Aura	But if the DOCTYPE is not ignored, the browser/reader must be able to understand the entities, since they are part of the DOCTYPE. It might be that the corresponding character is not in the readers font, but that is another issue of course.

Advert

Advert