Sigil 0.9.8 changes in-line style codes

tetrault · 07-16-2017, 10:55 PM

I have chapters with:
<body style="my style choices">
My text 1.
My text 2.
etc.

Sigil repeatedly changes that to:
<body>
My text 1.
My text 2.
etc.

It does this for some chapters in my book but not others. I can find no explanation for this bizarre behavior. Any ideas?

theducks · 07-16-2017, 11:37 PM

Quote:

Originally Posted by tetrault

I have chapters with:
<body style="my style choices">
My text 1.
My text 2.
etc.

Sigil repeatedly changes that to:
<body>
My text 1.
My text 2.
etc.

It does this for some chapters in my book but not others. I can find no explanation for this bizarre behavior. Any ideas?

It only does that if you edit (more that fix a letter/word in Book view
IMHO Avoid editing in BV, just use it to locate thing, then switch to CV

Notjohn · 07-17-2017, 07:29 AM

I would go further and advise not using Book View at all. (Well, I do use it to check external hyperlinks.) Really, it has virtually no purpose now that the Preview Panel is available.

DiapDealer · 07-17-2017, 08:35 AM

Quote:

Originally Posted by tetrault

I have chapters with:
<body style="my style choices">
My text 1.
My text 2.
etc.

Sigil repeatedly changes that to:
<body>
My text 1.
My text 2.
etc.

It does this for some chapters in my book but not others. I can find no explanation for this bizarre behavior. Any ideas?

Can you give detailed steps to make this happen? Even editing in Book View (or reformatting/prettifying) I can't duplicate what you describe.

EDIT: I've seen some elements pick up some of their parents' attributes when deleting/reinserting linebreaks in BookView, but that's just par for the course when editing in Book View. It does what it thinks is best to maintain the look that is desired. But I've never seen Book View editing remove attributes from a parent element before.

As others have mentioned: if you have very specific coding conventions that you would prefer to maintain, then editing in Book View is not something you want to do.

tetrault · 07-17-2017, 08:58 PM

I do almost all my work in book view, and I have for years. If I wanted to write my books in HTML code and rarely look at “book view,” then I would avoid the buggy Sigil and use BBEdit.

The whole point of Sigil is to write formatted text and to edit HTML code only as needed. Sigil didn’t come into being so we could write 99% of our work in code view. There are scores of apps that have that ability.

Turtle91 · 07-17-2017, 09:55 PM

Quote:

Originally Posted by tetrault

I do almost all my work in book view, and I have for years. If I wanted to write my books in HTML code and rarely look at “book view,” then I would avoid the buggy Sigil and use BBEdit.

The whole point of Sigil is to write formatted text and to edit HTML code only as needed. Sigil didn’t come into being so we could write 99% of our work in code view. There are scores of apps that have that ability.

Ummm.... actually...I think you have that exactly backwards.

But, whatever works for you!

Just one little bit of advice... The Sigil developers are great people who spend a lot of their time helping people out - for free. I'm sure you will get more positive response if you don't come in to the Sigil forum and start putting Sigil down...Buggy?!?!?

Cheers,

KevinH · 07-17-2017, 10:45 PM

None of the 0.8 or 0.9 changes in Sigil are related to this issue. Sigil BookView has been doing that for a very very long time. It is an inherent part of editing live html in QtWebkit. The DOM tree that you are editing "live" is internal to that Qt widget and is really not under Sigil direct control. You may not like what it does but it is generating perfectly valid xhtml code. Just code you do not personally like.

To get around the limitations of editing a DOM tree of a web-page live, many authors use Word or LibreOffice to write their book employing proper styles. They then convert this to filtered html and import it into Sigil. They then use Sigil in CodeView with live Preview to make changes if they care about the actual code generated. There are Sigil plugins to help import properly styled word filtered html into proper xhtml in an epub. You may want to try working things that way.

Most standalone xml/html editors understand nothing about epub structure, the opf,and guide, the nav, toc generation, index generation, semantic setting, embedding fonts, etc, nor allow global file name changes with automatic link and opf updating. This is Sigil's main reason for being.

Serious editing in BookView is all but deprecated as it does not provide enough control of the actual html generated for professional epub developers and is not as effective or efficient for real authors to use as real dedicated writing apps like Word and LibreOffice.

Notjohn · 07-18-2017, 07:14 AM

Quote:

Originally Posted by tetrault

I do almost all my work in book view, and I have for years. If I wanted to write my books in HTML code and rarely look at “book view,” then I would avoid the buggy Sigil and use BBEdit.

The whole point of Sigil is to write formatted text and to edit HTML code only as needed. Sigil didn’t come into being so we could write 99% of our work in code view. There are scores of apps that have that ability.

Well, I only began using Sigil in January 2012, so I can't comment on what Sigil's developer intended before that time, but I certainly wasn't under the impression that Book View was the way to go at that time. (I may be wrong, but I think that was some version of 0.7.x.) Unless I'm revising a previously published ebook, I only ever feed it clean html (cleaned from Word).

If I'm just tweaking text, I'm perfectly comfortable doing it in Code View. If I'm adding a new chapter or completing rewriting a lengthy section, then I do it in Word, paste that *.docx into a Word-to-html cleaner, and paste the html into Code View. (I don't have the patience to muck about with Styles. Word, for me, is just a super-fast typewriter. I love it!)

KevinH · 07-18-2017, 10:37 AM

BTW:

I have been playing around with BookView in Sigil-0.9.8 on a Mac with the following test case and I simply can not get the style in the body tag to disappear or the underlying text to get it added:

Here is my testcase:

Code:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
  "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body style="text-decoration:underline;">
<p>My text 1.<br/></p>
<p>This is a line of text</p>
<p>My text 2.</p>
</body>
</html>

I added lines in the body (such as "This is a line of text"), I added returns, I cut and pasted lines, I swapped the order of the lines.

Everytime when I go back to CodeView I see the style in the body tag is still there and none of the p tags have added anything.

So exactly what sequence of events are you using to see a valid style in the body tag disappear?

DiapDealer · 07-18-2017, 11:24 AM

I couldn't get the style attribute of the body tag to go away in my testing either, Kevin. I could get child p elements to pick up the body's style attributes, but only by joining two paragraphs in BV (by deleting/backspacing) and then splitting them again.

Hitch · 07-18-2017, 05:03 PM

Quote:

Originally Posted by tetrault

I do almost all my work in book view, and I have for years. If I wanted to write my books in HTML code and rarely look at “book view,” then I would avoid the buggy Sigil and use BBEdit.

The whole point of Sigil is to write formatted text and to edit HTML code only as needed. Sigil didn’t come into being so we could write 99% of our work in code view. There are scores of apps that have that ability.

As Turtle said, you have that quite backwards. Not even in the very original days of Sigil did Valloric really intend that Bookview was going to be the "way to go" on Sigil. In fact, a topic of some very serious discussion around here for the last few years is doing away with Bookview entirely, because that's really not the intended use. And some of that discussion is centered around this very misapprehension--that it's meant to be a word-processor that makes ePUBs. There are indeed other programs for that, like Jutoh, AWP, Pages and the like.

Sigil is not a WYSIWYG editor for the non-tecchie. It's an HTML/CSS editor for the creation of ePUBs for those persons who already have the technical skill to make them without the software. It's a handy tool--it builds the OPF and NCX, will build an HTML TOC for you, if you wish, etc.--but it's not meant to be the Word or Pages of ePUB-making. It's not iBooks iAuthor, so that people can type whatever in the front end and have all the heavy lifting done behind the scenes, in the backend.

If you've been using Sigil for years, then you've surely seen this stated here any number of times, and the progress of Sigil has surely made the intended use clear--e.g., Preview mode. What early purpose is Preview, if the intent is that work should be done in BookView?

It's your work, but if you work in BV, you are going to have glitches like that which you've experienced. The way to solve that is to use Sigil as intended, not as it's not. But obviously, it's your time and effort.

Good luck.

Hitch

st_albert · 07-18-2017, 07:38 PM

Quote:

Originally Posted by KevinH

Most standalone xml/html editors understand nothing about epub structure, the opf,and guide, the nav, toc generation, index generation, semantic setting, embedding fonts, etc, nor allow global file name changes with automatic link and opf updating. This is Sigil's main reason for being.

As one who got my start in creating/editing epubs before Sigil was much more than a gleam in Valloric's eye (and what an eye that was!), I can authoritatively say that the above quote is a serious understatement.

As for creating content, my preferred path is LibreOffice, using a predefined set of custom styles and no direct formatting; conversion to epub via the ODT import plugin, carefully configured with a matching set of customized config.xml and epub.css files (which match the LO custom styles to the corresponding CSS styles in the epub. Then, only tweaking of the epub is required in Sigil. Typically, adding more complete metadata, applying semantics, adding dropcaps and smallcaps to certain paragraphs, maybe changing the fonts, etc.

For those of you who swing in the direction of MS Word, there are similar plugins to import from docx itself, or filtered Word HTML, or Toxaris' Word macros (which do lots of good stuff besides epub export).

Hitch's post above mentioned several other good options. So there are many good workflows for those who wish to compose in a WYSIWYG environment, and end up with an epub that preserves the "look and feel" of the document, without suffering the slings and arrows imposed by Sigil's (actually, QtWebkit) book view .

[asseverator] An artist needs to understand his tools. If you desire to create ebooks with a certain "look and feel," you need to determine what that "look and feel" looks and feels like, and also how to achieve it in the several formats you will want to produce. This latter requires a certain minimal knowledge of html and css and what goes on under the hood of an epub or mobi file. In other words, you can't escape code view completely. [/asseverator]

Now, that said, @tetrault, you are not alone. There have been several users here in this forum who have insisted that they (for various reasons) really, really prefer to edit/compose in Sigil Book View. I do not judge them. I do, however suggest that complaining about The Way Book View Works in this forum is generally unproductive.

IMHO, YMMV, et cetera.

Albert

Notjohn · 07-21-2017, 08:33 AM

Quote:

As for creating content, my preferred path is LibreOffice

I'm told that LibreOffice has the advantage (over OpenOffice) of saving as *.docx.

Do you find that it has other advantages as well? Does it do a good job of exporting as PDF?

Thanks!

st_albert · 07-21-2017, 11:22 AM

Quote:

Originally Posted by Notjohn

I'm told that LibreOffice has the advantage (over OpenOffice) of saving as *.docx.

Do you find that it has other advantages as well? Does it do a good job of exporting as PDF?

Thanks!

Hmm, I had no idea that OpenOffice could not save as .docx, whereas LO-generated .docx seems to work OK in Word. So do .xlsx files.

As for other advantages, I'm not sure. Back when LibreOffice forked off from OpenOffice, I went with LO, since it seemed to me at the time that LO had the more active development and support. My impression was that OO has since closed the gap, though.

LO's pdf generation is adequate for my uses. For me the most challenging use would be when printing, say, nametags or mailing labels from a LO table whose layout must precisely match a specific form. IIRC, the label templates supplied by, say, Avery for MS Word may or may not work in LO, but even if they don't, you can easily create your own table to the specifications of the label sheet (usually given along with the template).

Albert

BetterRed · 07-21-2017, 06:46 PM

@Notjohn, st_albert - I'm not sure which OpenOffice you're referring to, but if it's Apache OpenOffice then it can save DOCX.

I too read that LO is better at PDF, but my experience is contrary to that, for me Word is better. I had a couple of documents where PDFs from Word were sub-prime, they required further editing in Acrobat. The PDFs from Libre and Apache Writer were both significantly worse.

But I suspect that's a result of 30 years of using Word versus limited usage of Writer, and most of that was in OOo on Solaris, which reflects st_albert's assertion : "An artist needs to understand his tools."

BR

07-16-2017, 10:55 PM	#1
tetrault Enthusiast Posts: 26 Karma: 2010 Join Date: Jul 2015 Device: Kindle 3	Sigil 0.9.8 changes in-line style codes I have chapters with: <body style="my style choices"> <p>My text 1.</p> <p>My text 2.</p> etc. Sigil repeatedly changes that to: <body> <p style="my style choices">My text 1.</p> <p style="my style choices">My text 2.</p> etc. It does this for some chapters in my book but not others. I can find no explanation for this bizarre behavior. Any ideas?

07-17-2017, 08:58 PM	#5
tetrault Enthusiast Posts: 26 Karma: 2010 Join Date: Jul 2015 Device: Kindle 3	I do almost all my work in book view, and I have for years. If I wanted to write my books in HTML code and rarely look at “book view,” then I would avoid the buggy Sigil and use BBEdit. The whole point of Sigil is to write formatted text and to edit HTML code only as needed. Sigil didn’t come into being so we could write 99% of our work in code view. There are scores of apps that have that ability. Last edited by tetrault; 07-17-2017 at 09:18 PM. Reason: Didn‘t read all of previous post.

07-18-2017, 10:37 AM	#9
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	BTW: I have been playing around with BookView in Sigil-0.9.8 on a Mac with the following test case and I simply can not get the style in the body tag to disappear or the underlying text to get it added: Here is my testcase: Code: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title></title> </head> <body style="text-decoration:underline;"> <p>My text 1.<br/></p> <p>This is a line of text</p> <p>My text 2.</p> </body> </html> I added lines in the body (such as "This is a line of text"), I added returns, I cut and pasted lines, I swapped the order of the lines. Everytime when I go back to CodeView I see the style in the body tag is still there and none of the p tags have added anything. So exactly what sequence of events are you using to see a valid style in the body tag disappear? Last edited by KevinH; 07-18-2017 at 12:24 PM.

07-21-2017, 06:46 PM	#15
BetterRed null operator (he/him) Posts: 20,568 Karma: 26954694 Join Date: Mar 2012 Location: Sydney Australia Device: none	@Notjohn, st_albert - I'm not sure which OpenOffice you're referring to, but if it's Apache OpenOffice then it can save DOCX. I too read that LO is better at PDF, but my experience is contrary to that, for me Word is better. I had a couple of documents where PDFs from Word were sub-prime, they required further editing in Acrobat. The PDFs from Libre and Apache Writer were both significantly worse. But I suspect that's a result of 30 years of using Word versus limited usage of Writer, and most of that was in OOo on Solaris, which reflects st_albert's assertion : "An artist needs to understand his tools." BR Last edited by BetterRed; 07-21-2017 at 06:48 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Style poetry - line break on verse	ramsaa	Sigil	15	10-22-2013 04:28 PM
Line breaks with no style	therealjoeblow	Conversion	5	11-01-2011 11:51 PM
exit codes for command line apps	nharrison66	Calibre	0	02-11-2011 12:53 AM
Sigil Style Sheets	crutledge	Sigil	3	10-06-2010 08:48 AM
Sigil et la feuille de style	roger64	Software	3	03-30-2010 09:23 PM

07-17-2017, 07:29 AM	#3
Notjohn mostly an observer Posts: 1,515 Karma: 987654 Join Date: Dec 2012 Device: Kindle	I would go further and advise not using Book View at all. (Well, I do use it to check external hyperlinks.) Really, it has virtually no purpose now that the Preview Panel is available.

07-17-2017, 10:45 PM	#7
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	None of the 0.8 or 0.9 changes in Sigil are related to this issue. Sigil BookView has been doing that for a very very long time. It is an inherent part of editing live html in QtWebkit. The DOM tree that you are editing "live" is internal to that Qt widget and is really not under Sigil direct control. You may not like what it does but it is generating perfectly valid xhtml code. Just code you do not personally like. To get around the limitations of editing a DOM tree of a web-page live, many authors use Word or LibreOffice to write their book employing proper styles. They then convert this to filtered html and import it into Sigil. They then use Sigil in CodeView with live Preview to make changes if they care about the actual code generated. There are Sigil plugins to help import properly styled word filtered html into proper xhtml in an epub. You may want to try working things that way. Most standalone xml/html editors understand nothing about epub structure, the opf,and guide, the nav, toc generation, index generation, semantic setting, embedding fonts, etc, nor allow global file name changes with automatic link and opf updating. This is Sigil's main reason for being. Serious editing in BookView is all but deprecated as it does not provide enough control of the actual html generated for professional epub developers and is not as effective or efficient for real authors to use as real dedicated writing apps like Word and LibreOffice.

07-18-2017, 11:24 AM	#10
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I couldn't get the style attribute of the body tag to go away in my testing either, Kevin. I could get child p elements to pick up the body's style attributes, but only by joining two paragraphs in BV (by deleting/backspacing) and then splitting them again.