Hi Armin, I reported the bugs to the LO bugzilla. After finding out that AOO sarted the svg import stuff and LO adopted/is adopting it I started to look at AOO. So the current bugs I found are somewhere here: https://www.libreoffice.org/bugzilla/buglist.cgi?component=Drawing&product=LibreOffice&query_format=advanced&resolution=---&order=bug_id%20DESC&query_based_on= starting at 64457 and ending at about 64550 (so somewhere in between this to bug IDs I think) >There is an interactive gradient edit mode, have you seen it? It's >a little bit hidden...
Thanks for the hint will look at this one. Because I thought that the old gradient stuff can be also done in the svg way I thought of replacing the old gradient with the new one. For example the Border value could be also done with the hight and width of the gradient in the svg way (at least that's what I thought). But if that's not possible I guess we would have to have Gradient and SVGGradient (was thinking like Gradient + SVGGradient == newawesomeAOOgradient). regards. On 07.06.2013 at 10:16 AM, "Armin Le Grand" wrote:Hi bugreporter99, I see no changes to the old gradient sizes; that's because these are historically grown and should not be touched at all. They do not have own pos/size or whatever attributes, they are just using the area they are set at. Historically (a lot has changed since then, but to make clear why it is as it is): - The area wich is maximally covered (and needs to be painted) is calculated in pixels (no double precision) - This leads to a boundrect - The to be filled geometry is set as mask - Number of steps (as Integer) is calculated - For left/R/T/B an integer add is calculyted to shrink that rect (radial: same, ellipse: different) - In a loop for n steps the rectangle is shrunk by these values, but there were 'if's to not let it overlap itself - The rectangle is filled with a calculated color with rect or ellipse This cannot even be direclty mapped to a transformation (mix of local/discrete coordinate system) and depends on object rotation (!). It was a lot of work to get this mapped to transformations to 'emulate' it in primitive rendering at all (argh), but it works now. Today a primitive is used, all is in double precision. Still, the basic principle from the older days has to be used (the boundrect in world coordinates) to make it look the same, you do not want older loaded files to look diffeent, do you? BTW: There is an interactive gradient edit mode, have you seen it? It's a little bit hidden. Open draw, create a shape with gradient, in the drawing toolber (normally at the bottom) there is a 'effects' DropDown (normally on rotation). Drop it down (or undock it), there are more interesting functions there... For the SVG gradients we will have better/changed UI; I am thinking about a dialog form and also interactive support if possible. Suggestions welcome ;-) E.G.: Have it as a new fill mode (then two: Gradient and SVGGradient) or as one? One means to change the UI i nthe dialog on gradient selection change, also need a method to determine what kind of gradient to create newly (old ones still need to be creatable). And and and... HTH! On 06.06.2013 22:23, bugreporte...@hushmail.com wrote: > 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-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
