[scribus-dev] HTML import rewritten

Sun Aug 26 09:48:53 UTC 2012

Hi ale,

On 23.8.2012 15:18, ale rimoldi wrote:
> hi jan,
> 
> i think that what is needed is a README in the plugin folder
> summarizing the features implemented (and eventually your future plan).
> 
> you should also upload the patch to the bug tracker, explaining why the
> current plugin should be replaced.
> 
> and you should add the handling of embedded images i've implemented
> (embedded images should not be included as text in the .sla file!)
> if you want you can just ignore them as i did, if you want to do it
> well, you can insert them as embedded images (or better as normal
> images, since i fear that many people won't understand what is
> happening because they have never used embedded images...)
> 
> personally, i like how you implemented... now let's see if somebody
> adres to commit it to trunk!

I should be able to find some time for all those modifications during
the next week. Let me get back to you on that once I have everything ready.

Thanks
Jan

> 
> ciao
> a.l.e
> 
>> 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