Sigil’s Future Direction (Post 0.4.x)

[theducks]

Originally Posted by user_none

I'm not about to add support for Apple's non-standard, industry destroying, money grubbing practices.

Infinete Loop is only a few miles from here. I have Eggs.
Would you like a message delivered

[user_none]

I hate settings dialogs. 90% of things in them do not matter. Do not be surprised if it "slips" to a later release.

<rant> One thing in particular I keep hearing is the ability to set a default font in book view. Sigil is not a reading app, if you want a particular font then specify it in the file. Also, the good thing about a standard default font is it is very easy to tell if the file has specified a font.
</rant>

[theducks]

Originally Posted by user_none

I hate settings dialogs. 90% of things in them do not matter. Do not be surprised if it "slips" to a later release.

<rant> One thing in particular I keep hearing is the ability to set a default font in book view. Sigil is not a reading app, if you want a particular font then specify it in the file. Also, the good thing about a standard default font is it is very easy to tell if the file has specified a font.
</rant>

I like the fact that Sigil only shows what is coded within the book (that include using a systems default).
If the user has set their System font for tired eyes, I would expect Sigil to only honor that if using a (non-specified) system default

[Jellby]

Originally Posted by user_none

One thing in particular I keep hearing is the ability to set a default font in book view. Sigil is not a reading app, if you want a particular font then specify it in the file. Also, the good thing about a standard default font is it is very easy to tell if the file has specified a font.

While I understand your point, letting the user choose his/her preferred fonts, colours, etc. should be a feature of every app, although they can rely on system-wide settings.

While it's not a reading app, the book view should serve as a previewer (or otherwise, why is it there at all?), and changing the font could be useful in some cases.

If you don't want to implement a preferences dialog with all sorts of things (book view font among them), maybe you could just set some "default css" that is applied only to book view, and is not included in the ePUB.

[crutledge]

Originally Posted by user_none

I hate settings dialogs. 90% of things in them do not matter. Do not be surprised if it "slips" to a later release.

<rant> One thing in particular I keep hearing is the ability to set a default font in book view. Sigil is not a reading app, if you want a particular font then specify it in the file. Also, the good thing about a standard default font is it is very easy to tell if the file has specified a font.
</rant>

According to that line of thinking, no font would be used in Sigil and nothing could be read unless a font is speified in the file.

Having to reset the font size for each section is a PITA.

Some things should be global iaw the user's desires.

[charleski]

Originally Posted by user_none

<rant> One thing in particular I keep hearing is the ability to set a default font in book view. Sigil is not a reading app, if you want a particular font then specify it in the file. Also, the good thing about a standard default font is it is very easy to tell if the file has specified a font.
</rant>

One thing I know for certain is that is we were to introduce that then we'd get people complaining that the book looked fine on their PC, but ended up using a completely different font on their reader. It just introduces more possibility for confusion.

As it is right now, Sigil's Book View follows the rules for default handling of fonts that are specified in the standards - what you're seeing are the defaults built into Webkit. If you don't specify anything in the css you're telling the User Agent to decide for itself, and Sigil reflects that. Adding user preferences for this sort of thing would break the WYSIWYG model and that's too high a price to pay for something that the user can already do very easily by specifying their preference in the correct place, which is in the css.

[theducks]

Originally Posted by charleski

One thing I know for certain is that is we were to introduce that then we'd get people complaining that the book looked fine on their PC, but ended up using a completely different font on their reader. It just introduces more possibility for confusion.

As it is right now, Sigil's Book View follows the rules for default handling of fonts that are specified in the standards - what you're seeing are the defaults built into Webkit. If you don't specify anything in the css you're telling the User Agent to decide for itself, and Sigil reflects that. Adding user preferences for this sort of thing would break the WYSIWYG model and that's too high a price to pay for something that the user can already do very easily by specifying their preference in the correct place, which is in the css.

Actually, this issue exists if non-common fonts are not embedded. The device uses the fall-back, where the font may have been available to the PC/Sigil.

[charleski]

Unfortunately there's no way to prevent Webkit from using font information available to the host system, or restrict it to a subset. But at least this way anyone who runs into the problem will know that the place to fix it is in the css, rather than trying to alter a preference in Sigil that will have no effect on the ereader whatsoever.

An increasing number of ereaders are coming out with a variety of fonts available as stock (the iPad [though you need to add Apple's magic file to enable them properly], Kobo Touch and Sony T1) and if their UAs are correctly coded those fonts should be exposed and usable from the css without having to embed them.

[Ahmad Samir]

FWIW, in Linux, Sigil (qtwebkit) seems to use the "Times" family in the BV, so you can control the font Sigil uses in the BV using an alias, something like this in ~/.fonts.conf:

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
 <alias binding="same">
   <family>Times</family>
   <accept>
   <family>DejaVu Sans</family>
   </accept>
 </alias>
</fontconfig>

here I made it use the "DejaVu Sans" family, use the font you prefer (to get the exact font names, just look at the font settings dialogue in your DE (KDE, GNOME... etc)).

N.B. If you use KDE, ~/.fonts.conf probably already exists, so just add this part before the closing </fontconfig> at the bottom of the file:

 <alias binding="same">
   <family>Times</family>
   <accept>
   <family>DejaVu Sans</family>
   </accept>
 </alias>

This is on Fedora Rawhide, Sigil built locally from source against Qt 4.8.0.

[Freeshadow]

Originally Posted by user_none

Announced is one thing being incorporated into the spec is another. Right now EPUB 3 is still in draft status. I'm not even going to think about EPUB 3 until it's finalized. Also, it will still be some time before EPUB 3 makes it to Sigil simply because when it is ratified the vast majority of devices on the market won't support it.

Right now Apple's iBooks is the only thing that supports HTML5 and CSS3. However, this is at the expense of creating non-compliant files that are only guaranteed to work in iBooks. I'm not about to add support for Apple's non-standard, industry destroying, money grubbing practices.

Karma ASAP for that - I promise

[graycyn]

Originally Posted by user_none

Right now Apple's iBooks is the only thing that supports HTML5 and CSS3. However, this is at the expense of creating non-compliant files that are only guaranteed to work in iBooks. I'm not about to add support for Apple's non-standard, industry destroying, money grubbing practices.

Thank you!

BTW, I never use the WYSIWYG part of Sigil either, so I wouldn't cry any if it went away.

Please keep the program cross-platform though!

[cybmole]

I use WYSIWYG lots - please keep it.

[mediax]

As a "dabbler" in Sigil, my main use of it has been for correcting blatant errors in texts (spelling, punctuation, etc.), rather than structural editing (for want of a better phrase). A WYSISYG interface is brilliant for that purpose, as it hides all the code, etc that I don't want to change!

With regard to the issue of validity of epubs, I agree that Sigil shouldn't enforce validity at all times - but please provide a nice, easily accessible way of checking validity that doesn't require processing the file in a separate application (sounds like a good job for a plugin?).

with regard to the issue of making Sigil non-cross platform - I'm a Linux user, so you can probably guess my position

Good luck - whatever direction you end up taking Sigil.

[user_none]

Originally Posted by mediax

With regard to the issue of validity of epubs, I agree that Sigil shouldn't enforce validity at all times - but please provide a nice, easily accessible way of checking validity that doesn't require processing the file in a separate application (sounds like a good job for a plugin?).

It's already there. Click the green check mark in the tool bar to run FlightCrew which is the integrated conformance checker.

[kovidgoyal]

On plugin language: I vote for python

One reason that you may not have considered is that using python means that plugin authors can re-use modular code from calibre to do various tasks.