Hi Doitsu,
Yes, please do.
KevinH

Here you go:

The result should be pretty much similar to rubeus's plugin, but this version will either insert the font css at the beginning of the first stylesheet or create a new stylesheet.

Instructions:

1. Select Manage Plugins, enable Use Bundled Python, if it isn't already selected, click Add Plugin and the select the zip file.
2. Select the plugin via Plugins > Edit > CSSFromFonts.

Note: This is a Python 3-only plugin, if you're using the Linux version of Sigil, please download the updated version, which'll automatically select the Python 3 interpreter.

License: GNU General Public License v3 (GPL-3)

I always wondered why an auto @font was not part of the Add (existing files) Fonts process.

The only question was: Where
For me, I like it in page_styles.css

***** Edited to add: *****
OK, never mind. I ran it on a different Kubuntu version, with a built-from-scratch Sigil (0.9.4, Qt-5.4.1), and it ran fine. I guess I'll be uninstalling that quirky sigil package.

I'll leave this post here just in case someone else runs into the same problem, but moderators please feel free to delete it if you want.

Edit #2. It seems the sigil package was not guilty after all. See below.
***********************


Hmm, I'm having trouble with this plugin. Here's the error message:
But testplugin says I do have PIL installed (as I should).

I am using Sigil version 0.9.5, Qt 5.5.1, from the Ubuntu package for Kubuntu 16.04 LTS (Xenial Xerus).

This Sigil package is known to be somewhat quirky, so maybe that's part of it. Otherwise, could be PEBCAK (i.e. operator error).

Has anyone else run into this?

Albert

It's not a Python 2 vs 3 thing is it? The order the supported engine attribute appears for a plugin affects which Python will be used (should both Py2 and Py3 interpreters be configured). In other words: the plugin in this thread could be using a different Python interpreter than the test plugin is if the supported engine attributes are reversed (and both pythons are configured).

That may not be what's happening here, but that's why I only ever configure one python interpreter at a time.

EDIT: The test plugin only supports python3, and Doitsu's will default to python2 if both are configured in the plugin manager. I get the "no PIL module" error myself if I have both 2 & 3 interpreters configured (since my python 2 environment doesn't have pillow installed. If I unconfigure the python 2 interpreter (plugin manager) it allows Doitsu's plugin to use Python 3 instead -- which does have pillow installed.

@Albert: Even though the error message says PIL it's actually looking for Pillow, which is a PIL compatible fork.

should list:

It could also be a Python2/3 issue. If you have paths for both interpreters defined, try deleting the Python 2.7 path and or the Python 3.4 path.

Yes, I think it was a python2/3 issue. I had installed python3-pil but not python-pil. After installing the latter, it seems to work.

But I think I'll keep my home-built 0.9.5 for now.

Thanks for the input, both you and DiapDealer!

Albert

I got reports that the plugin won't work with Python 2.7 and changed plugin.xml so that it'll select the Python 3.4 interpreter.

If you're a Linux user please download the updated version.

(If you're using the Windows version and the embedded interpreter, you won't have to download this update.)

For the record ... it seemed to work fine for me with Python 2.7. (Linux or Windows) * shrug*

But since Python 3 has been required for (and/or included with) Sigil for quite some time now, I can't really blame anyone for dropping Python 2 support for their plugins either. I did it with my latest; and can't foresee me continuing to jump through the hoops necessary to support both in future plugins.

Those sticking with older versions of Sigil still have the option of installing an external Python 3 interpreter if they can't live without a Python 3-only plugin. So it's not like anyone is being completely left behind or anything.

Yes I think it is time we retire python 2.7 support. Almost all of the plugins we have will run on both, but our internal python 3.4 (or later) (and linked version on Linux) comes with lxml, html5lib, cssutils, cssselect, Pillow, tk, six, regex and chardet all guaranteed to be there and available for the user.

Supporting Python 2.7 code does not seem to add any real value over and above what python 3.4 provides and removing it would certainly simplify things. Older Sigil users can still use an external Python 3 interface (after manually adding the right modules) to run plugins that are only python3.

So since Doitsu, DiapDealer, Toxaris and myself probably account for the majority of current Sigil plugin developers, are you all okay with moving to Python 3 only after our upcoming Sigil 0.9.6 release?

Please let me know what you think?

Thanks,

KevinH

I'm OK with that, because there really is no benefit in maintaining Python 2.7 compatibility, especially since the Windows version comes with a Python 3.4 interpreter and all required libraries.

Also the last time I checked, only one or two very old plugins with relatively low download counts supported only Python 2.7.
I.e., this move won't cause problems for the majority of end users, because all existing plugins will automatically fall back to Python 3.4 in the absence of a Python 2.7 path.

The only conceivable snag I can think of would be people who may be using custom--but unshared--plugins that require Python 2.7.x. If there are any, though, I can't imagine it affecting very many at all. And I'd be more than willing to help anyone convert such plugins to Python 3 if they came forward.

The only question would be how to handle python2.7-only plugins moving forward. Do we simply allow them to error out, or display a message that the plugin needs to be updated to Python 3 before it will work (or perhaps simply display them in the Plugin Manager in red and allow them to error)?

If we do remove 2.7 support (and I think I'm for it), I'm assuming the "engine" tag in the plugin.xml file would become superfluous? It certainly wouldn't need to be displayed in the Plugin Manager anymore.

@DiapDealer: I had another look at the official plugin list and found only one plugin that requires Python 2.7: smoothRemove, which the author seems to have abandoned. (He hasn't logged in since 2014.)

It's also a tad too dangerous for my taste, but that's a different matter.
I'm sure that either you or KevinH could write a much safer Python 3.4-compatible replacement in 10 minutes or so. :-)

Yes, I will happily help fix any python 2.7 plugins to work with python 3 (even private ones).

If we remove "engine" from the Plugin Management table, it would free up enough space to add either "oslist" (which is kind of meaningless since that is checked to make sure it matches when the plugin is installed) or better I think to add the "description" field to help users remember just what the hell that plugin does.

We could then add in support for auto sorting (and remember to disable it when adding or deleting items in the same row to prevent the row form moving out from under you) when we update things.

Also removing the >= Python 2.7 lines in the Dialog will free up enough space to add one or even two more user-assignable icons to plugins (and therefore shortcut keys to launch them).

How does that sound?

KevinH

Sounds fine to me.