[scribus-dev] HTML import rewritten

[Jan Zelený]

Hi ale,

On 8.8.2012 09:43, ale rimoldi wrote:
> hi jan,
> 
> 
>> I've rewritten HTML import plugin for gettext and I'd like to offer it
>> to you. I've developed it on current 1.4 branch but I don't suppose it
>> will be different for devel branch.
> 
> i skimmed through the code and it looks very clean!
> 
> i've noticed that you retain some more formatting... but it's hard to
> spot what the differences are against the previous impoter...

Yeah, that's why I decided to send you whole files instead of the diff.
The original part of the code was so small that I reformatted it to the
style I'm used to. I guess I was lazy to switch my vim config to the new
style every time :)

> do you have a list of feature you have implemented?
> a list of bugs that your plugin fixes?
> some html files and pdf showing the difference?

Basically the plugin has been designed to be fully compatible with
current behavior. I can check again to make sure it still is. Do you
perhaps have a test set of HTML code that would verify that?

That means everything that was supported should be still supported,
maybe with minor visual nuances that can be in most cases easily corrected.

The main advantage now is flexibility. The plugin can be now very easily
extended to support more tags or more features as long as they are
supported by gettext and HTML specification.

For user, the biggest difference is a support for HTML attribute
"style". In that attribute you can define various styles that are valid
CSS and the plugin will recognize them.  The definition is the same as
in standard CSS:

attribute: value[; attribute: value[ ... ]]

Later definition overwrites all previous ones. Some attributes have
pre-defined visual appearance, that can be changed by defining
additional style modifications.

List of supported tags:
ul, ol, li, pre, br, a, sup, sub, img, center, p, pre, div, h1 - h6,
code, em, i, strong, b, u , ins, del

List of supported CSS attributes and allowed values:
font-weight: bold/normal
font-style: italic/normal
font-family: <font_string>
color: <color_string>
text-align: left, right, center, justify
text-decoration: underline, strikethrough, none

Font string can be defined as arbitrary string representation of font
loaded by Scribus. I tested both family name (e.g. DejaVu Sans) and full
font name (e.g. DejaVu Sans Bold), both should work as far as the font
is loaded in Scribus.

Color string was kinda blind shooting on my part. Color names defined by
the document are working and IIRC hex codes are working as well. I think
I even saw a definition like rgb(255,0,0) to go through and work. If you
can verify all this, that'd be helpful, I don't have much time left
these days. One thought: I think that in case of hexa and rgb
definition, the color integrity might be compromised since I don't
perform any conversion based on color model. I have no idea whether it's
done on lower levels. To give you an idea what am I doning in the code,
I just call font->setColor(value); that's it.

margin-top, margin-bottom, margin-left, font-size:
these can have size values defined either as fixed size or relative size
XX px - fixed size in points
XX pt - fixed size in points
XX % - relative size in percentage
XX em - relative size, similar to percentage
+XX px/pt/%/em - absolute/relative size respectively, added to the
current size (i.e. +50px -> use current size plus 50 more points)

Code-wise, the approach has been changed completely. The visual
appearance for every element is now stored only in s style string. These
strings are then parsed and stored in form of stack of gtParagraphStyle
structures which are then pushed/popped as HTML parsing goes on. I hope
this description is sufficient.

> i did a short test and your plugin seems to work correctly so,
> basically, once the its advantages are clear, i'm for its inclusion in
> 1.5svn (and probably also in 1.4.2svn, except if it brings changes that
> could "harm" existing workflows):

I did some testing as well, however I don't pretend to fully cover the
functionality. For example images, links and preformatted text are
completely untested since I haven't had a real usage for them yet.

> but: while going through your plugin i noticed that it does not have my
> patch for images embedded in the html file (which are typical for html
> files created by open/libreoffice)
> 
> http://bugs.scribus.net/view.php?id=10686
> http://bugs.scribus.net/view.php?id=11015
> 
> i understand that you have changed so many changes that a diff does not
> really make sense, but now we have the "problem" that it's harder to
> check if all old features/behaviors are still in :-)

I believe I didn't change anything in this behavior so it will probably
still be there. I'll look into it.

>> Please let me know what do you think of the plugin. It should be 100%
>> backwards compatible with previous version plus it has a lot of other
>> possibilities. Over time I intend to implement some more extensions
>> and send it to you if you are interested. I already have a bunch of
>> patches sort of depending on this plugin. If you accept the plugin,
>> I'll send you the rest.
> 
> i think that we are very interested in getting your improvements!
> 
> do you have a list of things you have already done or plan to do?

Yes, I have a bunch of fixes in gettext, one extension of Python
scripting interface and then I have some hack-ish solutions for some
problems I've been having with automated scribus launching. I will send
you everything probably during this week. Some patches will be good to
go, some will be just to outline what problems I've been having, I'm
certain there are better solutions for them.

Also I started to do some work on rewriting scribus core to support
headless run but then I got stuck with the HTML plugin so I will need to
get back on track with that once I have some time. Hope that will be soon.


Best regards
Jan