&()nbsp , &()#160 , inconsistencies??

[Hitch]

Originally Posted by DiapDealer

I could never, in good conscience, recommend splitting in Book View. Too much potential for soupy markup being introduced. Having said that however, the process for WYSIWYG users assumes that markers will be manually inserted one at a time (for later mass splitting) or one-at-a-time "Split at Cursor" actions will be performed. I have a feeling that yours and NotJohn's definitions of "easier" are simply different.

Probably. I do it the same way that Turtle does--I regex them in, immediately preceding whatever element/class I've used for the section heads. Then split. I actually think using BV for this is dicier than using CV, because the results MAY (not necessarily will) be unexpected as to the location of the split. Not that it's unfixable, of course, but...{shrug}.

Hitch

[DiapDealer]

Originally Posted by Hitch

Probably. I do it the same way that Turtle does--I regex them in, immediately preceding whatever element/class I've used for the section heads. Then split. I actually think using BV for this is dicier than using CV, because the results MAY (not necessarily will) be unexpected as to the location of the split. Not that it's unfixable, of course, but...{shrug}.

Hitch

I do the same for the same reasons. The "cursor" position in Book View is a bit ambiguous (with respect to the underlying markup). I'll still occasionally do the one-off manual "Split at Cursor" in Code View (as opposed to wholesale split markers inserted via regex S&R), so I do those splits/marks in Code View where the cursor position is never ambiguous.

Splitting into nested div situations, coupled with the wrong Tidy Settings, cured me of doing such things in Book View long ago.

[signum]

Originally Posted by Notjohn

But then I've been writing web pages for twenty years, so I'm comfortable looking at html.

I, too, am quite comfortable looking at html, but I think you've missed the point I was trying to make. During the final read-through, I'm looking at the visual effect of the entire page, among other things. I'm reading the text word-for-word looking for things, such as mis-placed hyphens, that don't just pop out at you in code view. In my opinion, the markup codes obscure the final result at this point. Hyphens are very easy to remove with just a tap of the backspace or delete key, without having to switch to the code view. Improperly aligned headings pop out at just a glance. It's all visual at this point after I've done all the spell checking, removed all validation errors and made sure all curly quotes match.

I try to think like the end user, who probably will never see the html markup.

FWIW, my first browsers were ViolaWWW, Cello and NCSA Mosaic on a 286 running Windows 3.1. Perhaps you remember them?

[icallaci]

I use both the preview pane and book view. I size the preview pane to be very narrow, while book view is approximately the same dimensions as the ereader I use. That way, I can quickly check how tables, hanging indents, etc. look in my own personal ereader, while making sure any changes I've made don't completely screw up the format on ereaders with other screen dimensions. Easier than constantly resizing the same window.

[Turtle91]

Originally Posted by icallaci

I use both the preview pane and book view. I size the preview pane to be very narrow, while book view is approximately the same dimensions as the ereader I use. That way, I can quickly check how tables, hanging indents, etc. look in my own personal ereader, while making sure any changes I've made don't completely screw up the format on ereaders with other screen dimensions. Easier than constantly resizing the same window.

That's what I had done as well until I found out you can use the preview pane for both...just double click the header on the preview pane to toggle between docked and un-docked. you can set the un-docked pane to any size/dimension.

[Hitch]

Originally Posted by signum

I, too, am quite comfortable looking at html, but I think you've missed the point I was trying to make. During the final read-through, I'm looking at the visual effect of the entire page, among other things. I'm reading the text word-for-word looking for things, such as mis-placed hyphens, that don't just pop out at you in code view. In my opinion, the markup codes obscure the final result at this point. Hyphens are very easy to remove with just a tap of the backspace or delete key, without having to switch to the code view. Improperly aligned headings pop out at just a glance. It's all visual at this point after I've done all the spell checking, removed all validation errors and made sure all curly quotes match.

I try to think like the end user, who probably will never see the html markup.

Well, yeah, but they're not going to look at the book like you do, anyway, whether it's BV, Preview, or ADE, or anything else. They'll see it however they see it, on whatever devices they have, fonts they choose, etc., no? Myself, I test the books on ADE, or (better yet) Sony Reader. That gives me a much better visual check, IMHO.

FWIW, my first browsers were ViolaWWW, Cello and NCSA Mosaic on a 286 running Windows 3.1. Perhaps you remember them?

Nah--I used Lynx. Still do, as a matter of fact. It was my first "browser," per se. Before Lynx, I used ye olden Archie, along with Jughead and Veronica for Gopher. (Using, way back, OS/2, which I thought was really great, myself. Died for lack o'love (drivers)). Added 3.1 in...what, spring of '88? Or thereabouts? We still have a box here running OS/2. Hell, for that matter, we have one here running Win98 (used to drive a Mill!).

Hitch

[BetterRed]

Originally Posted by Hitch

Using, way back, OS/2, which I thought was really great, myself.

AFAIK the NYC-TA still thinks the same. As of April 2012 (OS/2's 25th birthday) hundreds of OS/2 boxes were still in use in the Metrocard swipe terminal network. And some US regional banks still had OS/2 based ATM's.

Aah for the days, when the only way to go was to use gopher and wais. I'd forgotten about veronica

BR

[Notjohn]

Originally Posted by signum

I'm looking at the visual effect of the entire page, among other things.

Right! Thus the Preview Pane, which IMHO is the best thing that's happened to e-book creation since the debut of Sigil itself. I love them both and can't imagine finalizing a book any other way. WYSIWYG!

I usually size them about 60/40, plus a narrow sliver for the Book Browser on the left.

[sjkramer]

Using Sigil 8.6 on a Mac running OSX 10.10.3. In all the versions of Sigil I've used (at least the last several), I have never had satisfactory handling of nonbreaking spaces. I have had a book rejected from the Google Play store for using nbsps and have been told to switch to #x00A0. Maybe no one cares about Google Play anymore (does it exist?) nonetheless, I have abide by my distributors wishes and not get files rejected.

In Sigil, the #x00A0s get converted into regular spaces. I never ever cross-my-heart-hope-to-die edit in Book View. And I've added #x00A0 to the preserve entities list, all to no avail. Basically, once I'm done editing in Sigil I have to have a separate step of opening in Calibre. And then I can never open the book in Sigil again from that point on. And I really do prefer Sigil.

[KevinH]

What are your Sigil settings for Preserve Entities? And do you have Tidy on open/ save enabled.

If it matters, named entities are not allowed in html5 and so Sigil will be moving to using numeric enties (either hex or not) as defaults for preserving entities.

KevinH

Originally Posted by sjkramer

Using Sigil 8.6 on a Mac running OSX 10.10.3. In all the versions of Sigil I've used (at least the last several), I have never had satisfactory handling of nonbreaking spaces. I have had a book rejected from the Google Play store for using nbsps and have been told to switch to #x00A0. Maybe no one cares about Google Play anymore (does it exist?) nonetheless, I have abide by my distributors wishes and not get files rejected.

In Sigil, the #x00A0s get converted into regular spaces. I never ever cross-my-heart-hope-to-die edit in Book View. And I've added #x00A0 to the preserve entities list, all to no avail. Basically, once I'm done editing in Sigil I have to have a separate step of opening in Calibre. And then I can never open the book in Sigil again from that point on. And I really do prefer Sigil.

[Notjohn]

Originally Posted by KevinH

If it matters, named entities are not allowed in html5 and so Sigil will be moving to using numeric enties (either hex or not) as defaults for preserving entities.

KevinH

It is to weep! Are there really people who can remember what those numeric entities MEAN?

Whenever I do a search for an entity, I always specify "named" in the Google line.

I hope you will alert us when this change goes into effect, so I can stop updating the software! I'm still using WordStar 7d (more recent than Lynx, tee hee), so I'm comfortable wearing old clothes.

[KevinH]

Hi,

You misunderstand me. These are only default settings for new users. You (and even new users) will be able to use both named and numeric entities by changing the Preserve Entities preferences. It is just that new empty documents in Sigil 0.9 will default to the xA0 char instead of nbsp so that it is generating technically correct code for both epub2 and epub3 type ebooks.

I was just trying to explain that html5 has moved away from non-xml named entities since they are an attack vector (previously you could create your own named entities that are in fact malicious by having them expand to yet another named entity to recursively use up memory). So as an ebook author getting to know some common numeric entities might prove useful for generating ebooks that must pass through epub3 validation (and it seems even epub2 validation for some ebook stores).

Hope I explained things better this time.

KevinH

Originally Posted by Notjohn

It is to weep! Are there really people who can remember what those numeric entities MEAN?

Whenever I do a search for an entity, I always specify "named" in the Google line.

I hope you will alert us when this change goes into effect, so I can stop updating the software! I'm still using WordStar 7d (more recent than Lynx, tee hee), so I'm comfortable wearing old clothes.

[theducks]

Originally Posted by Notjohn

It is to weep! Are there really people who can remember what those numeric entities MEAN?

Whenever I do a search for an entity, I always specify "named" in the Google line.

I hope you will alert us when this change goes into effect, so I can stop updating the software! I'm still using WordStar 7d (more recent than Lynx, tee hee), so I'm comfortable wearing old clothes.

I used to remember a few ASCII codes that I used frequently (CHR$(27) ).
That was a FEW out of 127 (the standard set). For the rest, a cheat sheet

For Unicode, it is a cheat BINDER
What were they thinking

Add in the subtle differences of various dashes, quotes... (they can be brutal to pick out stand alone from separate cheat sheet pages. endash, minus easy peasy )

[Hitch]

Originally Posted by theducks

I used to remember a few ASCII codes that I used frequently (CHR$(27) ).
That was a FEW out of 127 (the standard set). For the rest, a cheat sheet

For Unicode, it is a cheat BINDER
What were they thinking

Add in the subtle differences of various dashes, quotes... (they can be brutal to pick out stand alone from separate cheat sheet pages. endash, minus easy peasy )

Hell, I'm still trying to convince Joomla's editor that an EMDASH really exists, rather than -- . It's pretty annoying.

(Yes, it's somewhat offtopic, but...)

Hitch

[MickiTee]

Originally Posted by KevinH

Hi,
I was just trying to explain that html5 has moved away from non-xml named entities since they are an attack vector (previously you could create your own named entities that are in fact malicious by having them expand to yet another named entity to recursively use up memory). So as an ebook author getting to know some common numeric entities might prove useful for generating ebooks that must pass through epub3 validation (and it seems even epub2 validation for some ebook stores).

KevinH

Will you be updating the Insert Character functionality to replace the existing entities with HEX unicode values in V0.9?