Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
Received-SPF: pass (nike.apache.org: domain of bugreporter99@hushmail.com
 designates 65.39.178.239 as permitted sender)
MIME-Version: 1.0
Date: Thu, 06 Jun 2013 22:23:18 +0200
To: "Regina Henschel" <rb.henschel@t-online.de>,
 "Armin Le Grand" <armin.le.grand@me.com>, "dev" <dev@openoffice.apache.org>,
 "LibreOffice Developer List" <libreoffice@lists.freedesktop.org>
Subject: Re: Draw, make some changes to gradients
From: bugreporter99@hushmail.com
In-Reply-To: <51AE5CB2.3060301@apache.org>
References: <20130603154630.1B1D02007D@smtp.hushmail.com>
 <51ACC5BC.8060102@t-online.de> <20130604133653.724D9A6E38@smtp.hushmail.com>
 <51AE0455.7030208@t-online.de> <51AE1EA5.7090909@me.com>
 <51AE2CFD.2000903@t-online.de> <51AE5CB2.3060301@apache.org>
Content-Type: multipart/alternative;
	boundary="=_9d578b1964f8b4031d44d8fc00aac3dc"
Message-Id: <20130606202319.0791B2007F@smtp.hushmail.com>

--=_9d578b1964f8b4031d44d8fc00aac3dc
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"

Hi,

what do you think about the way the size of the gradient should be set
(in the future)?
I came up with 4 ways:
1. Edit-Box for width and height
   width/height is set in percentage
2. Edit-Box for width and height
   width/height is set absolute (mm,cm,inch,...)
3. Edit-Box for width and height
   width/height is set as a dot seperated value
    -> 1.0 would be the same width/height as parent width/height
4. NO Edit-Box for width and hight
   handles on the gradient(on canvas) are used to change the size

(the Edit Boxes can be seen in my mockup I sent in the first mail)
   http://temp-share.com/show/f3Ygit6Xn

My opinion
1.
   cause the size of the gradient can be bigger then the parent's
   the value would become bigger than 100% ->weird
2.
   if the size is changed and one want to set it to the parent's size
   it's not that simple (unless there is a reset button)
3.
   ok, 1,0 would be the same size as the parent's
4.
   cause in my opinion Draw is mostly used to draw simple stuff
   the handles may confuse some people and it may be harder to
implement
   (although I would like this option as well, cause that's the way
    Inkscape does it)
btw. should the Border Edit Box(in the gradient tab) be replaced with
a width/height Edit Box?
I think if one can set the height and widht the border Edit Box
becomes obsolete???
where can I get the latest snapshot of AOO
is this one ok?:
https://cwiki.apache.org/OOOUSERS/development-snapshot-builds.html#DevelopmentSnapshotBuilds-AOOSnapshotfullsets

I use the LO version from here:
http://dev-builds.libreoffice.org/daily/
On 04.06.2013 at 11:31 PM, "Andrea Pescetti"  wrote:Forwarding Armin's
and Regina's answers, below, to the original poster. 
bugreporter99: please follow 
http://mail-archives.apache.org/mod_mbox/openoffice-dev/ to read
answers 
(or subscribe to this list, same link). Andrea

Regina Henschel wrote:
> Hi Armin,
>
> Armin Le Grand schrieb:
>> Hi Regina and bugreporter99,
>>
>> a very interesting topic...
>> @bugreporter99: Which tasks did you commit for SVG? I did the SVG
>> import, so these should got to AOO probably, did they...?
>>
>> Using multiple color steps in old gradients: A good idea, I already
>> thought about it. Problem is (as often) that we would need a ODF
change
>> for it. Regina, could you think about something like that, please?
>
> AOO has not yet implemented the  and
>  (ODF 1.2 section 16.40.2 and 16.40.3). They allow
> multiple stop-colors. The schema has
>   
> So in this gradient variant, it is already possible to use multiple
> color steps (and some other nice stuff).
>
> Therefore I think, that in a first step this should be implemented.
>
> We
>> have start and end colors, in-between colors would have to be some
value
>> pair of float [0..1] and color value...
>
> The element svg:stop has the attributes
> svg:offset, svg:stop-color, and svg:stop-opacity.
> The offset is double (actual from 0..1) or percent, stop-color is
> #rrggbb, and opacity is double (from 0..1). All is already in the
standard.
>
>>
>> Transparency: I thought myself about this; the current 100-0%
setting to
>> blent the start/end color against black is really not very useful;
it's
>> just handy to not change the color yourself. If adding an alpha
value to
>> each color definition, these value entries in the UI could be
reused. I
>> would guess users who know more modern apps think these values are
>> exactly that, sigh. Also needs a ODF change, though.
>
> It is possible already using stop-opacity. I don't think, that we
should
> go the way to try to get additional attributes/subelements into
> draw:gradient, but implement the two svg-gradients.
>
>>
>> BoundRects of old gradients: This is old stuff some people thought
about
>> 16-20 years ago and of course not state of the art; it was a handy
way
>> to draw these gradients at all (think 640kb systems) and got into
ODF
>> later, sigh, but cannot be changed
>>
>> SVG gradients: We already have these in the ODF spec, thus it will
be
>> better to go forward and offer these for the current draw objects
>> directly., I think. Regina, what about ODF here and that it only
allows
>> one of the SVG mapping modes, I think both should be possible.
>
> Currently only objectBoundingBox is allowed. I think, that AOO
should
> have it implemented in a way, that both svg:gradientUnits methods
are
> possible. If an application supports a feature, it is easier to get
it
> into ODF. It can be done by using a gradientUnits in an own
namespace
> and later on, when it is in the ODF, map it to the official one on
> reading. For such a namespace, discussion with Thorsten would be
useful.
>
>>
>> With all this, do not forget: More transparency makes all stuff
more
>> fancy, BUT also makes printing more expensive (preparation,
handling)
>> and also PDF export, especially PDF1/A stuff that does not allow
>> transparencies at all...
>
> But that is needed already for proper rendering of svg graphics. So
> hopefully many parts can be reused.
>
> I'm not the right person to do it, but shouldn't be the way to use
> modern graphic cards for the calculations?
>
> Kind regards
> Regina
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--=_9d578b1964f8b4031d44d8fc00aac3dc--