From jz at janzeleny.cz  Tue Aug  7 21:33:08 2012
From: jz at janzeleny.cz (=?ISO-8859-1?Q?Jan_Zelen=FD?=)
Date: Tue, 07 Aug 2012 23:33:08 +0200
Subject: [scribus-dev] HTML import rewritten
Message-ID: <50218994.2070509@janzeleny.cz>

Hi guys,
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.

Since the change is pretty extensive, sending you git formatted patch
wouldn't do much good. Hence I'm sending you the entire
scribus/plugins/htmlim directory. To "apply" my changes, just copy all
files to your Scribus checkout.

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.


As a last think, I should note that development of the plugin has been
sponsored by MS Info s.r.o. from Czech Republic


Thank you for your opinion
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: htmlim.tar.bz2
Type: application/octet-stream
Size: 6865 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20120807/4627fada/attachment.obj>

From ale.comp_06 at xox.ch  Wed Aug  8 07:43:47 2012
From: ale.comp_06 at xox.ch (ale rimoldi)
Date: Wed, 8 Aug 2012 09:43:47 +0200
Subject: [scribus-dev] HTML import rewritten
In-Reply-To: <50218994.2070509@janzeleny.cz>
References: <50218994.2070509@janzeleny.cz>
Message-ID: <20120808094347.0dd4cdbe@eiseiseis>

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...

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?

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):


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 :-)


> 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?

have a nice day!
a.l.e


From jz at janzeleny.cz  Mon Aug 13 18:20:59 2012
From: jz at janzeleny.cz (=?ISO-8859-1?Q?Jan_Zelen=FD?=)
Date: Mon, 13 Aug 2012 20:20:59 +0200
Subject: [scribus-dev] HTML import rewritten
In-Reply-To: <20120808094347.0dd4cdbe@eiseiseis>
References: <50218994.2070509@janzeleny.cz> <20120808094347.0dd4cdbe@eiseiseis>
Message-ID: <5029458B.7090901@janzeleny.cz>

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


From tsoots at gmail.com  Tue Aug 14 07:10:05 2012
From: tsoots at gmail.com (Riku Leino)
Date: Tue, 14 Aug 2012 10:10:05 +0300
Subject: [scribus-dev] HTML import rewritten
In-Reply-To: <50218994.2070509@janzeleny.cz>
References: <50218994.2070509@janzeleny.cz>
Message-ID: <CAAtSkBd+K87Q_LMLRqtSj4KZEAu6-FpFA=DS38pBZfEwYPU_zQ@mail.gmail.com>

Hi

2012/8/8 Jan Zelen? <jz at janzeleny.cz>

> I've rewritten HTML import plugin for gettext
>

Nice job! Great to see someone working on gettext.

Riku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20120814/fb7c5e60/attachment.html>

From ale.comp_06 at xox.ch  Thu Aug 23 13:18:22 2012
From: ale.comp_06 at xox.ch (ale rimoldi)
Date: Thu, 23 Aug 2012 15:18:22 +0200
Subject: [scribus-dev] HTML import rewritten
In-Reply-To: <5029458B.7090901@janzeleny.cz>
References: <50218994.2070509@janzeleny.cz> <20120808094347.0dd4cdbe@eiseiseis>
	<5029458B.7090901@janzeleny.cz>
Message-ID: <20120823151822.62b8e320@eiseiseis>

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



From jz at janzeleny.cz  Sun Aug 26 09:48:53 2012
From: jz at janzeleny.cz (=?ISO-8859-1?Q?Jan_Zelen=FD?=)
Date: Sun, 26 Aug 2012 11:48:53 +0200
Subject: [scribus-dev] HTML import rewritten
In-Reply-To: <20120823151822.62b8e320@eiseiseis>
References: <50218994.2070509@janzeleny.cz> <20120808094347.0dd4cdbe@eiseiseis>
	<5029458B.7090901@janzeleny.cz> <20120823151822.62b8e320@eiseiseis>
Message-ID: <5039F105.1020808@janzeleny.cz>

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


