First of all, thank you for putting your time and effort in Sigil. I've only just started with it but it looks promising. The only real issue being that it's rather slow, but I understand that's mainly due to Webkit and you've already found a solution for that so hooray .

I'm really happy with the search and replace, which wasn't there before (or I've been blind), especially because it supports regular expressions. I'm having some trouble with them tough, but that seems to be because different flavours of regexps. I run into that with Calibre all the time, too. Anyway, I'll be trying some other regexp testers than the one I currently use because I'm beginning to suspect it differs from most other libraries in its interpretation of the expressions.

Something I'm pretty sure there is an issue with is sudden changes of text size. As you can see in the attached screenshot, the text size between to chapters differs though under the hood I can't see anything different. Sorry if this has been brought up before, I couldn't find it on the forums.

This is a plain text file that I imported and converted to LRF using Calibre. Since I don't have access to the original text file on this computer, I used Calibre to convert the LRF to HTML which I opend with Sigil.

Edit: Something else, when working in the split view, Sigil often crashes when switching between them.

FYI, I have access to Parallels Desktop for Mac OSX (a virtual machine) and I have Windows XP installed on it and installed Sigil for Windows.

I was able to load and manipulate the exact same large book in Sigil on Mac OS X side by side on the same machine with Sigil for Windows.

Even though Sigil for Windows was running in a virtual machine in a window on MacOSX, it was much much faster than how it operates on MacOSX natively.

The search and replace in Book view seemed to work much better under Windows (but after almost every change after a search or even simply hitting the chapter break button, the search start point even though I used Find Next reverted to the top of the file). Searching simply freaked things out on the Mac OSX native side.

The ToC wait was much shorter under Windows emulation and even manipulating the Book View window itself was much faster under Windows emulation.

In short, I would be better off running it under a virtual machine with its overhead than directly on the Mac itself.

This is strange. What compiler optimizations are being used for the Mac OSX build (-O2 ?) Are the binaries and executables being stripped to speed loading? Are the Qt libraries made with the same compiler optimizations?

Anyway, thought you would like to know that the speed issue seems to be Mac OS X specific.

If you want I can set up a build system under Mac OSX using gcc and do a build and see if I can see anything particularly weird going on.

<p class="calibre1"><span>I had to nod.</span></p>
<p class="calibre1"><span>"We're loading furniture right now. The ship is the Empress-out of Brysta, Nordla Lines. I'm Caron."</span></p>
<p class="calibre1"><span>"Is this your dangergeld?" I blurted.</span></p>
<p class="calibre1"><span>She laughed. "Not exactly. I started as a purser on the Brotherhood ships, but traveling got old. I liked dealing with cargo and making up shipments, handling the cube and stowage calculations-"</span></p>
<p class="calibre1"><span>Whhhheeee . . .</span></p>
<p class="calibre1"><span>"-Excuse me . . ." She was back at the cart, deftly jockeying two more crates into the net, without seeming to work up a sweat.</span></p>
<p class="calibre1"><span>Whheeeeppp . . .</span></p>
<p class="calibre1"><span>As the net lifted away, Caron returned. "So that's how I ended up here. I have a small farm not too far from Sigil, in the low hills north of the High Road. I spend my free time there."</span></p>

...because I want to italicalize (is that a word?) those paragraphs, using the following to replace them with:

Code:

<span class="sgc-5">$1

This works fine in RegExPal, RegExr (in which I could test the replace, too) and RegExpCheck 1.0 (offline application) which specifically mentions PERL-compatibility.

I've attached a screenshot of the offline version of RegExr, which I normally use, so if I'm not clear in my explanations, hopefully the image will be .

I'm really happy with the search and replace, which wasn't there before (or I've been blind), especially because it supports regular expressions. I'm having some trouble with them tough, but that seems to be because different flavours of regexps.

I've been meaning to add new entries to the FAQ relating to the regex and wildcard search engines, but I just can't find the time.

Here is the documentation for the QRegExp class used internally in Sigil. It documents these engines quite nicely.

Quote:

Originally Posted by Punksmurf

Something I'm pretty sure there is an issue with is sudden changes of text size. As you can see in the attached screenshot, the text size between to chapters differs though under the hood I can't see anything different. Sorry if this has been brought up before, I couldn't find it on the forums.

This is a plain text file that I imported and converted to LRF using Calibre. Since I don't have access to the original text file on this computer, I used Calibre to convert the LRF to HTML which I opend with Sigil.

I can see a <div> ending with the last chapter. Maybe it has some different styles applied? Have you also looked at how does the original calibre-produced epub look like in ADE?

This is probably related to the specific CSS styles you have in the document.

Quote:

Originally Posted by Punksmurf

Edit: Something else, when working in the split view, Sigil often crashes when switching between them.

It's quite probably related to a bug I fixed a few days ago. The fix will be in 0.1.6, which will be out soon.

Quote:

Originally Posted by KevinH

Even though Sigil for Windows was running in a virtual machine in a window on MacOSX, it was much much faster than how it operates on MacOSX natively.

That's horrible.

Quote:

Originally Posted by KevinH

(but after almost every change after a search or even simply hitting the chapter break button, the search start point even though I used Find Next reverted to the top of the file).

This should already be fixed in trunk.

Quote:

Originally Posted by KevinH

This is strange. What compiler optimizations are being used for the Mac OSX build (-O2 ?) Are the binaries and executables being stripped to speed loading? Are the Qt libraries made with the same compiler optimizations?

Sigil is built with -O3, but I don't know what the Qt libraries are built with. I use the precompiled ones from Nokia's site, but I'm pretty sure those are -O3 too. -O2 at the very least. Don't know for sure though.

Then again, it's always possible I screwed up the compile, although I highly doubt this.

Quote:

Originally Posted by KevinH

If you want I can set up a build system under Mac OSX using gcc and do a build and see if I can see anything particularly weird going on.

By all means, please do. Any help/insight you can provide is greatly appreciated. You can contact me by PM or email if you need help setting this up.

I've been meaning to add new entries to the FAQ relating to the regex and wildcard search engines, but I just can't find the time.

Hey, don't sweat it . You're doing a great job!

Quote:

Here is the documentation for the QRegExp class used internally in Sigil. It documents these engines quite nicely.

Hey thanks, that'll sure be helpful!
An important note I spotted (for those wanting to dabble in regexp search, too), is that DOTALL is always true:

Code:

Matches any character (including newline).

To get the normal dot-behaviour use

Code:

[^\r\n]

instead of '.'.

Quote:

I can see a <div> ending with the last chapter. Maybe it has some different styles applied? Have you also looked at how does the original calibre-produced epub look like in ADE?

This is probably related to the specific CSS styles you have in the document.

Sharp eye, there! I don't have ADE but I tried Calibre's viewer and indeed there the text suddenly enlarges too. After removing the </div> (and it's opening <div>) the problem was solved. Sorry for having accused you for it!

Quote:

It's quite probably related to a bug I fixed a few days ago. The fix will be in 0.1.6, which will be out soon.

Great!

Quote:

Originally Posted by Valloric

You are using non-greedy matching applied to specific quantifiers. Those aren't supported by QRegExp. To achieve a similar effect, set the "Minimal matching" option in the F&R dialog.

Thanks for the hint! I'll look at the docs! Luckily, this expression isn't depending on it.. just a leftover from trying to find the right one.

Quote:

Originally Posted by Valloric

... and the group reference is not "$#", but "\#".

Thanks, yet again. Haven't got to the point of trying to replace yet, but you're saving me a headache there .

But it won't replace! Not anything... I began with a space, and thought that was the problem, but a number of different strings yielded no results either. Other search/replace queries I've done work fine however (chapeau!).

But it won't replace! Not anything... I began with a space, and thought that was the problem, but a number of different strings yielded no results either. Other search/replace queries I've done work fine however (chapeau!).

FYI: I finished my build on MacOSX from source. The good news is that the build was very very clean and used -O3 optimization as you said. The bad news is that the slow speed is still there. My guess is that Qt on Mac OSX is simply not being optimized or is just darn slow. Because of the impact of larger html files and given how lightening fast Tidy is, my guess is the problem is related to the Qt html widget and/or redrawing. If that is the case, unless there is some way to split the large html books into smaller pieces automatically (some type of chapter by chapter auto splitting? - or a really smart dom parsing routine) and then assigning a different Qt html widget for each segment, I am not sure what is anything can be done.

Since X11 is now integrated right into Mac OS X (not an add-on anymore since Mac OS X 10.5), I tried to find a version of qt-x11 to rebuild against just to see how it compares for speed to native Qt but qt-x11 for Mac OS X doesn't seem to exist anyplace on the Qt (nokia) site anymore.

The only other thing is building Qt from source itself against X11 on Mac OS X just to see? If I get some free time I will do that.

I also have access to a Linux box (still running Fedora 8 - so no Qt - 4.5.3 pieces installed) that once I update to Fedora 11 or 12, I will try it for comparison speed purposes.

Hope this info is useful. Please let me know if there is anything I can test or do to help.