Sigil Prettify Code - Page 2

KevinH · 05-11-2025, 08:29 AM

Is there some other inherited css that impacts it. Fire up PageEdit's Inspector and position your cursor on that br tag and look exactly at the style information in and around that tag. Perhaps the margins on the parent tag controls that?

ElMiko · 05-11-2025, 01:10 PM

That's a neat little function...

This is what I got:

Code:

element.style {
}
.brheight {
    line-height: 1.75em;
}
.dedic {
    font-size: 1.1em;
    margin-top: 6em;
    margin-right: 5%;
    text-align: right;
}
p {
    display: block;
    margin-top: 0;
    margin-bottom: 0;
    margin-left: 0;
    margin-right: 0;
    line-height: 1.15em;
}
.calibre {
    display: block;
    font-family: serif;
    font-size: 1em;
    line-height: 1.1;
    margin-bottom: 0;
    margin-left: 0;
    margin-right: 0;
    margin-top: 0;
    padding-left: 0;
    padding-right: 0;
    page-break-before: always;
    text-align: justify;
}

with the "line-height" values for ".calibre" and "p" overridden (correctly) by the "line-height" value in ".brheight".

Other properties that have strike-throughs (again, correctly, as far as I can tell) are "font-size" and "text-align" in ".calibre".

But still, no visual effect on the 's line-height

The code itself is:

Code:

<body class="calibre">
  <p class="dedic">For KevinH<br class="brheight"/>Who always manages<br/>to get it put together right</p>

(in PageEdit, the code looks slightly different since the isn't displayed as self-closing.)

KevinH · 05-11-2025, 02:15 PM

PageEdit and Preview do not keep end tags. They are a tree of nodes of different types with a single parent link and multiple children links. End tags only exist in xml/xhtml/html to make it clear where siblings and children end a new node begins so that the tree of nodes can be formed. This tree is often referred to as the DOM or DOM tree.

If you look in the Inspector and have it show the code and find the br tag please take a screen shot of it styles and post it here.

If there is a bug, it is in Chrome's layout engine which is used by the graphics library Qt, that both PageEdit and Preview use.

Just to test, cause I know it looks terrible, but please try applying an inline style attribute with the line height right inside the br tag itself (which should have highest priority in css) Did that impact anything?

ElMiko · 05-11-2025, 04:15 PM

I assume you mean something like:

Code:

<br style="line-height:1.5em;"/>

If so, that also yielded a whole lotta nothin'.

I also tried adding

Code:

display: inline;

to the css, in case that's what you were driving at, but that didn't do anything.

However, if i create a around the and add the "line-height: 1.5em;" property to the css for the it does work.

Not that this is an actual solution; that's super duct-tape-and-super-glue-style coding.

Also, please see the screengrab for " " being displayed as " " in PageEdit.

EDIT: Ha! I just realized that PageEdit's prettification inserts a line-break after tags...

EDIT2: FWIW, I opened the file in Sigil 0.7.2, and the preview (and ye olde Book View) correctly renders the line-height property.

KevinH · 05-11-2025, 05:22 PM

Sigil 0.7.2 does not use Qt Webengine it uses the very old QWebKit version and that is now full of security holes since it was never updated and eventually dropped in favour of QtWebEngine which is Chrome.

I am surprised that a br tag can not seem to have a line-height property but a span wrapping that tag can.

Did a web search ...

Ah this is a known thing ... inline tags line height are ignored. It is controlled by the parent block tag.

See this link for more info.

https://stackoverflow.com/questions/...s-not-work-why

Lots of things changed since the old html4 epub2 days. You can of course use css to make your br tag a block tag so that line-heights will work like the old days. See the bottom of that link for another link to more info.

ElMiko · 05-11-2025, 06:41 PM

Thanks, KevinH... Serves me right for waiting so long. That's going to be a drag to go back and fix across the library...

Looks like the closest thing to a working solution is:

Code:

{
    content: " ";
    display: block;
    margin: 0.5em 0;
}

...though I worry about these kinds of "tricks" creating problems down the line.

Turtle91 · 05-11-2025, 06:58 PM

I don’t think this would “cause problems down the line.” This is a visual issue that is determined by what each device’s rendering engine is, yeah? Some will display properly, others won’t (until their engine is updated anyway).
In the meantime, is only supposed to be a line feed, so it is inheriting line-height from its parent. If it’s critical to have that extra line-height in a line feed, then it should be included in the parent…if you are only looking for extra spaces between verses, then start a new line or something.

DiapDealer · 05-11-2025, 07:42 PM

The rendering in Sigil's webengine is never going to be indicative of how it looks on all other ebook rendering systems. The same was true of the WebKit renderer in the old version of Sigil as well. This is a non-starter in my opinion. There's no need to accommodate it with a change to your css to try and make new Sigil render like old Sigil. Doing so is probably chasing something that's not even an issue on reading devices/apps.

KevinH · 05-11-2025, 08:18 PM

Just for laughs, I did a web search and Sigil 0.7.2 was released in April of 2013 I believe. That is 12 years ago. Html, the web and even ebooks have changed enormously in that time. I am truly surprised that binary will even run on modern Windows platforms. The macOS version will not and I would bet the linux executable versions may have a few issues with glibc changes over that time as well. It is a real tribute to Microsoft that they have kept backwards compatibility for so very long.

BetterRed · 05-12-2025, 12:30 AM

Quote:

Originally Posted by KevinH

It is a real tribute to Microsoft that they have kept backwards compatibility for so very long.

That's a trait they inherited from IBM, and it's not just Windows:

Toxaris' EPUB Tools addin for Word hasn't been updated since 2018, not only does it work with latest versions of Word, it works better than it ever did. Example: it's second to none Dialogue checker used to stutter, stop, start and wedge as it parsed the text (it's a visual process), but with each release of Word (2016/19/21/24) Dialogue checker has become smoother, faster, and much less likely to wedge.

BR

ElMiko · 05-12-2025, 01:19 AM

Quote:

Originally Posted by KevinH

Just for laughs, I did a web search and Sigil 0.7.2 was released in April of 2013 I believe. That is 12 years ago. Html, the web and even ebooks have changed enormously in that time. I am truly surprised that binary will even run on modern Windows platforms. The macOS version will not and I would bet the linux executable versions may have a few issues with glibc changes over that time as well. It is a real tribute to Microsoft that they have kept backwards compatibility for so very long.

Yeah, when you guys got me thinking about the switch over, I checked the "About" information in the dropdown, and nearly fell out of my chair. Happy to give Microsoft a couple of fingersnaps, but I think It's also a testament to the quality of the program. Whatever bugs you guys were seeing on your end, the fact is, I don't think there's another single piece of software that I've used unupdated for so long... except maybe, like, Winamp!

KevinH · 05-12-2025, 10:09 AM

Yes the original Sigil software design and use and design of C++ classes, etc was quite good. It literally took me two years to get up to speed enough to feel comfortable and appreciate the design.

That said ...Tidy would occasionally eat your text, it crashed so much people had to constantly use save as, forced you to structure your epub into their structure, did not support html5, or epub3, or accessibility, had no plugins, no support for epubcheck, no support for css validation or css 3, relied on an out of date and unsafe QWebkit, and outdated Qt3 or Qt4, an outdated and cumbersome Xerces xml parser. Basically there is very little left on the old Sigil internals as we have had to replace most of them to make Sigil do what is needed to edit modern epubs. The number of crash bugs we have fixed since then was huge. To me good software should never crash.

And add to that the changes in the C++ language standards and in compilers, the old code base would never even compile on any modern system. Also, given operating systems evolve over time too, breakage is inevitable without constant upkeep, redesign, rewriting, and maintenance.

But to each their own.

05-11-2025, 04:15 PM	#19
ElMiko Addict Posts: 383 Karma: 65460 Join Date: Jun 2011 Device: Kindle	I assume you mean something like: Code: <br style="line-height:1.5em;"/> If so, that also yielded a whole lotta nothin'. I also tried adding Code: display: inline; to the css, in case that's what you were driving at, but that didn't do anything. However, if i create a <span> around the <br> and add the "line-height: 1.5em;" property to the css for the <span> it does work. Not that this is an actual solution; that's super duct-tape-and-super-glue-style coding. Also, please see the screengrab for "<br />" being displayed as "<br></br>" in PageEdit. EDIT: Ha! I just realized that PageEdit's prettification inserts a line-break after <br> tags... EDIT2: FWIW, I opened the file in Sigil 0.7.2, and the preview (and ye olde Book View) correctly renders the line-height property. Attached Thumbnails Last edited by ElMiko; 05-11-2025 at 04:39 PM.

05-11-2025, 05:22 PM	#20
KevinH Sigil Developer Posts: 8,477 Karma: 5703586 Join Date: Nov 2009 Device: many	Sigil 0.7.2 does not use Qt Webengine it uses the very old QWebKit version and that is now full of security holes since it was never updated and eventually dropped in favour of QtWebEngine which is Chrome. I am surprised that a br tag can not seem to have a line-height property but a span wrapping that tag can. Did a web search ... Ah this is a known thing ... inline tags line height are ignored. It is controlled by the parent block tag. See this link for more info. https://stackoverflow.com/questions/...s-not-work-why Lots of things changed since the old html4 epub2 days. You can of course use css to make your br tag a block tag so that line-heights will work like the old days. See the bottom of that link for another link to more info. Last edited by KevinH; 05-11-2025 at 05:48 PM.

05-11-2025, 06:41 PM	#21
ElMiko Addict Posts: 383 Karma: 65460 Join Date: Jun 2011 Device: Kindle	Thanks, KevinH... Serves me right for waiting so long. That's going to be a drag to go back and fix across the library... Looks like the closest thing to a working solution is: Code: { content: " "; display: block; margin: 0.5em 0; } ...though I worry about these kinds of "tricks" creating problems down the line.

05-11-2025, 06:58 PM	#22
Turtle91 A Hairy Wizard Posts: 3,311 Karma: 20171571 Join Date: Dec 2012 Location: Charleston, SC today Device: iPhone 15/11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire	I don’t think this would “cause problems down the line.” This is a visual issue that is determined by what each device’s rendering engine is, yeah? Some will display properly, others won’t (until their engine is updated anyway). In the meantime, <br/> is only supposed to be a line feed, so it is inheriting line-height from its parent. If it’s critical to have that extra line-height in a line feed, then it should be included in the parent…if you are only looking for extra spaces between verses, then start a new line <p class="space"> or something.

05-12-2025, 10:09 AM	#27
KevinH Sigil Developer Posts: 8,477 Karma: 5703586 Join Date: Nov 2009 Device: many	Yes the original Sigil software design and use and design of C++ classes, etc was quite good. It literally took me two years to get up to speed enough to feel comfortable and appreciate the design. That said ...Tidy would occasionally eat your text, it crashed so much people had to constantly use save as, forced you to structure your epub into their structure, did not support html5, or epub3, or accessibility, had no plugins, no support for epubcheck, no support for css validation or css 3, relied on an out of date and unsafe QWebkit, and outdated Qt3 or Qt4, an outdated and cumbersome Xerces xml parser. Basically there is very little left on the old Sigil internals as we have had to replace most of them to make Sigil do what is needed to edit modern epubs. The number of crash bugs we have fixed since then was huge. To me good software should never crash. And add to that the changes in the C++ language standards and in compilers, the old code base would never even compile on any modern system. Also, given operating systems evolve over time too, breakage is inevitable without constant upkeep, redesign, rewriting, and maintenance. But to each their own. Last edited by KevinH; 05-12-2025 at 10:24 AM.

05-11-2025, 08:29 AM	#16
KevinH Sigil Developer Posts: 8,477 Karma: 5703586 Join Date: Nov 2009 Device: many	Is there some other inherited css that impacts it. Fire up PageEdit's Inspector and position your cursor on that br tag and look exactly at the style information in and around that tag. Perhaps the margins on the parent tag controls that?

05-11-2025, 02:15 PM	#18
KevinH Sigil Developer Posts: 8,477 Karma: 5703586 Join Date: Nov 2009 Device: many	PageEdit and Preview do not keep end tags. They are a tree of nodes of different types with a single parent link and multiple children links. End tags only exist in xml/xhtml/html to make it clear where siblings and children end a new node begins so that the tree of nodes can be formed. This tree is often referred to as the DOM or DOM tree. If you look in the Inspector and have it show the code and find the br tag please take a screen shot of it styles and post it here. If there is a bug, it is in Chrome's layout engine which is used by the graphics library Qt, that both PageEdit and Preview use. Just to test, cause I know it looks terrible, but please try applying an inline style attribute with the line height right inside the br tag itself (which should have highest priority in css) Did that impact anything?

05-11-2025, 07:42 PM	#23
DiapDealer Grand Sorcerer Posts: 28,357 Karma: 203720150 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	The rendering in Sigil's webengine is never going to be indicative of how it looks on all other ebook rendering systems. The same was true of the WebKit renderer in the old version of Sigil as well. This is a non-starter in my opinion. There's no need to accommodate it with a change to your css to try and make new Sigil render like old Sigil. Doing so is probably chasing something that's not even an issue on reading devices/apps.

05-11-2025, 08:18 PM	#24
KevinH Sigil Developer Posts: 8,477 Karma: 5703586 Join Date: Nov 2009 Device: many	Just for laughs, I did a web search and Sigil 0.7.2 was released in April of 2013 I believe. That is 12 years ago. Html, the web and even ebooks have changed enormously in that time. I am truly surprised that binary will even run on modern Windows platforms. The macOS version will not and I would bet the linux executable versions may have a few issues with glibc changes over that time as well. It is a real tribute to Microsoft that they have kept backwards compatibility for so very long.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Code Hints in Sigil?	oston	Sigil	3	04-09-2024 03:27 PM
source code of sigil	Aymen Boss	Sigil	6	07-18-2018 11:51 PM
Collapse and expand code in Sigil	samirahmed007	Sigil	9	07-06-2017 09:44 AM
Sigil code hints	kakkalla	Sigil	12	05-13-2013 03:31 PM
Are the SGC_# a sigil code?	JaneFancher	Sigil	14	09-06-2010 04:08 AM