[scribus-dev] HTML import rewritten

Jan Zelený jz at janzeleny.cz
Tue Sep 4 19:44:08 UTC 2012


Hi everyone,
it's been some time but I have some progress to report. I've fixed the
embedded image bug. I used the original patch for that.

I also created a bug to track this effort:
http://bugs.scribus.net/view.php?id=11060

Since the archive is larger than allowed 4.1k attachment, I'm attaching
the archive with fixed sources to this email and linking this email to
the bug. Note that the archive still contains complete sources since the
diff is so extensive it is very likely to fail when applying (tried with
git couple months back).

Instead of the suggested readme file, I'd like to update the wiki page
in the scribus documentation:
http://wiki.scribus.net/canvas/Help:Manual_Importhtml

If you have any more questions, feel free to ask. I'll appreciate if
someone will push my changes into the upstream repo or comment what
needs to be changed to do that.

Thanks
Jan

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!
> 
> 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
> 
> 
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: htmlim.tar.bz2
Type: application/octet-stream
Size: 6897 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20120904/f5ee31d3/attachment.obj>


More information about the scribus-dev mailing list