whitespace eaten by pretty print

[AlanHK]

I have some text mimicking a report; needed to have text line up on several lines, since HTML doesnt have tabstops, only way I could think was to use a monospaced font.

so did this CSS:

.memo {
margin-top:2em;
margin-left: 2em;
text-indent:0em;
font-family: monospace;
font-size: .9em;
white-space: pre-wrap;
}

and text like:

<p class="memo">
AGENTS:
 Section Leader: Com Varlt, MW 69321
 Crew:           Horman Tilis MW 69345
                 Fal Korf AW 70958
                 Pague Lo Sig AW 70889 

PROGRESS TO DATE:
  Traced subject—Kmoat Vo Pranj—to Levels 415-426 inclusive.
</p>

And that worked perfectly. Looks as it does above with "CODE" tags.
But when I saved it, clean source collapses it to:

<p class="memo">AGENTS: Section Leader: Com Varlt, MW 69321 Crew: Horman Tilis MW 69345 Fal Korf AW 70958 Pague Lo Sig AW 70889 PROGRESS TO DATE: Traced subject—Kmoat Vo Pranj—to Levels 415-426 inclusive.</p>

Destroying the layout.

Eventually I tried using pre instead of p : <pre class="memo">
And that was safe from being reformatted.

I don't know if the pretty print can be made to check if whitespace should be preserved, but at least there is a work-around.

One reason I used p tags first was I was going to make AZW, and according to Amazon:
https://kdp.amazon.com/en_US/help/topic/A1JPUWCSD6F59O
Kindle does not support either <pre> or <tt>

But when I tried it, actually it does.
If I use Kindlegen on the <pre> coded text, Looking at the result in Calibre's Inspect, the AZW is identical: <pre class="memo">, while the KF7 has become <tt>.

[KevinH]

Does this only happen with prettyprint? It should not happen with a normal mend. As a normal mend should not touch whitespace. If so, that is expected behaviour.

As pretty print has no idea what your class in css has done. It simply tries to clean up and format whitespace and will only leave untouched pre and tt tags. The same issue will happen if you use css to make an inline tag into a block tag. Prettyprint reformats whitspace in html and does not pull in or grok the css that may change how tags are redefined.

[AlanHK]

I don't know what "mend" means.
This happens when I do a normal save, or r-click reformat/clean source.

It's obvious why this is happening; maybe "expected", but not ideal. It makes it impossible to use "whitespace" styles on most tags.

[KevinH]

What version of Sigil are you using? All recent versions do not auto run pretty print on save or open anymore for just this reason. They just allow you to run Mend that simply fixes errors but should not impact whitespace.

[KevinH]

I just tried your test case and when I use a right mouse click on this html document and select Reformat HTML -> Mend Code. All is fine and no whitespace is impacted.

When I use a right mouse click on this html document and select Reformat HTML -> Mend and Prettify Code, it, as expected, will play with the whitespace of text within tags that are not pre or tt. Your are using css to give a "p" tag properties like a "pre" tag but the pretty-print code has no idea what your css has done or will do. So if you have changed the whitespace handling in other tags, do not use Mend and Prettify as spacing is important to you, only use Mend Code.

[Tex2002ans]

Any specific reason why you are not using a <pre> tag for this?

Originally Posted by AlanHK

One reason I used p tags first was I was going to make AZW, and according to Amazon:
https://kdp.amazon.com/en_US/help/topic/A1JPUWCSD6F59O
Kindle does not support either <pre> or <tt>

But when I tried it, actually it does.
If I use Kindlegen on the <pre> coded text, Looking at the result in Calibre's Inspect, the AZW is identical: <pre class="memo">, while the KF7 has become <tt>.

I would trust the Kindle Publishing Guidelines over a lot of the info on their website (which is typically outdated and/or geared more towards a Word->Kindle workflow).

I attached a test EPUB:

Spoiler:

<pre>AGENTS:
 Section Leader: Com Varlt, MW 69321
 Crew:           Horman Tilis MW 69345
                 Fal Korf AW 70958
                 Pague Lo Sig AW 70889 

PROGRESS TO DATE:
  Traced subject—Kmoat Vo Pranj—to Levels 415-426 inclusive.
</pre>

<p class="memo">
AGENTS:
 Section Leader: Com Varlt, MW 69321
 Crew:           Horman Tilis MW 69345
                 Fal Korf AW 70958
                 Pague Lo Sig AW 70889 

PROGRESS TO DATE:
  Traced subject—Kmoat Vo Pranj—to Levels 415-426 inclusive.
</p>

with this CSS:

Spoiler:

.memo {
margin-top: 2em;
margin-left: 2em;
text-indent: 0em;
font-family: monospace;
font-size: .9em;
white-space: pre-wrap;
}

pre {
margin-top: 2em;
margin-left: 2em;
text-indent: 0em;
font-size: .9em;
}

The <p class="memo"> you put together looks fine in KF8, but absolutely falls apart in KF7:



Side Note: If I am messing with code that must keep very specific whitespace, I typically edit using Calibre's Prettify. 99.9% of the time I prefer Sigil's whitespace cleanup though.

[AlanHK]

Originally Posted by Tex2002ans

Any specific reason why you are not using a <pre> tag for this?

Yes, as I said, it's not supposed to be supported by Kindlegen. None of the built-in whitespace preserving tags are listed as supported. Even though it appears to be about the only way to do this reliably.
I'm not really bothered if something doesn't work in KF7, but obviously better if it does.

Anyway, it is valid to use whitespace styles on any tag.

So that pre works, while p is trashed doesn't seem to be desirable.

While Kevin pointed out that prettify is not automatic, it's easy to do it unaware of how it will affect important spacing in a section you aren't looking at or haven't reviewed yet.

So the lesson is: note if any whitespace styles are used and make them safe by applying them only to <pre> tags.

[AlanHK]

Originally Posted by KevinH

What version of Sigil are you using? All recent versions do not auto run pretty print on save or open anymore for just this reason. They just allow you to run Mend that simply fixes errors but should not impact whitespace.

Version 0.9.1
DiapDealer's latest build for XP. since that's what I'm running.
So I assume this is now obsolete and unsupported?

[KevinH]

That is up to DiapDealer. Recent versions of Qt have stopped trying to support Windows XP, and Microsoft has abandoned Xp. The real issue is that there have been a large number of Sigil bug fixes in each of the last 7 releases since 0.9.1 that fix serious bugs, many of which have remained hidden since even Sigil 0.7.4 days. I have no idea if Sigil 0.9.8 can be made to run on Xp or not.

Have you considered trying to run Windows 7 on that box? Or alternatively run Linux on it?
I have many older Macs that can't run new versions of OSX running Linux just to keep them useful to run print servers or act as a firewall bridge, etc.

Unfortunately, there is no long run future solution for Xp for anything using Qt (and that includes Sigil) that I know about.

As for support, we can try to help where possible but you will probably stumble into many of the bugs we have already fixed as time goes by. Perhaps Diapdealer can let us know the status for Xp support on Windows for the latest Qt 5.9.1 which I would like to upgrade to for the next release to hopefully get as many Qt bug fixes as possible into Sigil.

[DiapDealer]

I still hope to be able to pull many of the latest bugfixes into a new Windows Legacy release of Sigil sometime soon. But I'm afraid it's always going to be an "as is" release. Caveat emptor if you will.

Too much of Sigil's code (and the code of its dependencies) requires C++11 compliance which means that Visual Studio 2015 is fastly becoming a minimum requirement for compiling Sigil (and its dependencies) on Windows (which doesn't automatically disqualify XP, but Python 3.5+--which is built with VS2015--IS incompatible with XP which means a legacy Sigil will have to be backported to use Python 3.4).

The new community version of QtWebKit we'd like to use moving forward requires vs2015 and Windows 7 at a minimum. The precompiled binary versions of Qt5 that I may be able to start using again to build Windows Sigil releases (which would make my life so, so much easier) would leave both XP and Vista behind (with regard to Sigil compatibility).

So if I can cobble together something that uses Qt5.6 and Python 3.4 that will provide all the features and bugfixes of Sigil's latest code-base using vs2013 (or vs2015 if that proves impossible), then I will. But it will go largely unsupported, and it will likely be the last of its kind, unfortunately.

[AlanHK]

Originally Posted by KevinH

Have you considered trying to run Windows 7 on that box? Or alternatively run Linux on it?

The hardware could handle it. It's my workflow that is the issue. I'm dependent on a number of old softwares for my work, many of which have long ago stopped updating. They all work under XP quite well, but I'm dubious of running them on later versions. Whe I use Win 7 all I see is hassles with permissions and such and more and more bloat.

I know there are workarounds, like DOSBox, but I just can't face the inevitable hassles of changing platform. I've done it several times; from Unix to DOS to Win3, Mac System 6, 7, 9, Windows 2k, XP.... each time was hard.

Ironically, it's the free software, not the commercial, that is the problem. The many that require Qt have left me behind. Most I don't care as old versions work well enough. But Sigil (and Calibre) are ones I would like to keep current if I could.

I'd need to get another PC to test stuff rather than experiment with my work machine. Downtime more than a few days could be a big problem. Or maybe just swap in a new hard disk.

[JSWolf]

You can get Windows 7 Professional and run XP in a VM or you can get Windows 10 and dual boot XP.

But whatever you do, you need to dump XP as you'll be left farther and farther behind.

[KevinH]

So running Windows 7 or 10, you can run Xp in a VM at the same time? I never knew that. What VM works best to run Xp?

[DiapDealer]

Originally Posted by JSWolf

You can get Windows 7 Professional and run XP in a VM or you can get Windows 10 and dual boot XP.

But whatever you do, you need to dump XP as you'll be left farther and farther behind.

Jon, you need to realize people's reasons for keeping XP are their own. The fact that those reasons aren't very compelling to you, don't make those reasons any less valid.

Your "Dump XP" advice/campaign is pointless and unhelpful to those who are clearly not ready to do so--whether for reasons of workflow efficiency, hardware incompatibility, sheer nostalgia, or otherwise. They know what they're doing. They're not hanging on because "they didn't know" and need reminding.

I'm actually with AlanHK on this. I hate that free, opensource Qt projects are basically being forced to leave perfectly functioning OSes behind. Because to continue to support them AND look forward creates double the work for their maintainers. Not to mention not being able to avail themselves of important bug fixes in later versions of Qt by sticking with a version that's compatible (without jumping through massive hoops) with older systems.

But it's part of the problem with trying to maintain cross-platform compatibility with three different, and constantly evolving, platforms. Qt is the glue that makes that particular magic work. So something's constantly gotta give to accommodate it, unfortunately.

[DiapDealer]

Originally Posted by KevinH

So running Windows 7 or 10, you can run Xp in a VM at the same time? I never knew that. What VM works best to run Xp?

I use Oracle's VirtualBox to run all of my VMs (including Windows XP and Windows 7) on Linux. I've had it working on Windows, but I 'm not familiar with the specifics.

Provided the Host machine has enough memory and processing power, you can run several VM's simultaneously. XP would need very few resources to run comfortably on Windows 7 or 10 (provided, of course that Virtualbox doesn't drop support for XP guest machines at some point). The guest can even access portions of the host's file system that are specifically shared with it.