Summary: | Curves have round control points with black background | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | clio <fyvaao> |
Component: | Drawing | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED FIXED | QA Contact: | Bernhard Dippold <bernhard> |
Severity: | minor | ||
Priority: | medium | CC: | bernhard, thb, tlillqvist |
Version: | 3.3.2 RC1 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
URL: | http://nabble.documentfoundation.org/PATCH-Bug-35480-Curves-have-round-control-points-with-black-background-Draw-if-confirmed-td2718487.html | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Screenshot
Screenshot with GIMP save as PNG settings screenshot of a curve (without zoom) Screenshot Indexed Color Conversion Settings import png and convert to ppm - illustration of the bug Draw screenshot with transparent Bezier handles |
Created attachment 44734 [details]
Screenshot with GIMP save as PNG settings
The problem is in the file markers2.png. If saved (in GIMP) as illustrated on the screenshot (RGB Mode applied before saving it), then all looks fine in Draw. In hg.services.openoffice.org the file markers2.png have size 4.3kB, the newly saved file has the same size around 4.3kB, but the former file in LibO had 2.2kB size. Here is the screenshot with GIMP save as PNG settings.
Cannot reproduce - for me, the handles look perfectly round (and w/o black background). The different size is due to an optimization run over all png with "optipng" From the list:
> I can't check this with master, I have only dev-build 3.3.1. The
> screenshot is made with LibO 3.3.2 Final + Ubuntu 10.04 x86, and the
> problm exists on Windows XP virtual machine with 3.3.2(rc1?) (maybe
> the videocard matters? Intel GMA 900). With dev-build 3.3.1 with
> differently saved markers2.png, sometimes I see grey background (not
> black). But with the file posted here the round markers are
> transparent. With the markers2.png file from
> hg.services.openoffice.org they are transparent too. If the problem is
> not reproducible or already fixed in master, then never mind.
>
So, does not happen with 3.3.2 here, too. Tor, any chance to quickly check win32 is looking ok? Open Impress, draw a bezier curve, enable the "edit points" toolbar button, press ctrl-A to display all control points.
On a different notebook with Windows Vista (with NVidia GeForce 7000M if it matters), the controls have black background too. I use Galaxy theme with small icons (but it seems that this behavior doesn't depend on themes - checked on Linux). Checked on windows - does not happen here. Clio, you're sure you're not looking onto a bezier control point that's *exactly* on top of a normal (rectangular) curve point? can you try moving that bezier point away? Created attachment 44859 [details]
screenshot of a curve (without zoom)
Here is how the curve looks like (Linux) (without zoom)
>Open Impress, draw a bezier curve, enable the "edit
points" toolbar button, press ctrl-A to display all control points.
Draw, not Impress. I got why you can't reproduc it. Open Draw, not Impress. In Impress and Writer there another markers used (markers.png).
Created attachment 44900 [details]
Screenshot Indexed Color Conversion Settings
It is not necessary to have image in RGB mode. It can be converted to indexed colors as shown in this screenshot. The size decrease to 3.0 kB (PNG compression is 6).
Eh. Indeed. Sorry for that - and actually having two marker designs for the two apps is, err, surprising and suboptimal. For the bug: markers2.png *does* contain transparency, so I'd rather fix the png filter, than the file. Created attachment 45068 [details]
import png and convert to ppm - illustration of the bug
Here is another bug that seems can be fixed along with this. Look at the attached file. There are 2 png's saved in GIMP with and without option "Save color values for transparent pixels". They are imported correctly. But if you export them to PPM, you will notice that the transparency of the first PNG turned into black.
Sorry, but the latest screenshot is invalid (and the second patch on the list too), because saving with these options will result in White background (not transparent) and I didn't notice that first because the background of the paper is white too. Hardly I can fix the bug with the filter, so if there someone who could fix it then it's great. IMHO, in case the bug itself is not fixed before 3.4 release, we should fix at least the picture markers2.png. Bug is present in 13_LibO-3.4.0_beta4_win discussion as per: http://nabble.documentfoundation.org/PATCH-Bug-35480-Curves-have-round-control-points-with-black-background-Draw-if-confirmed-td2718487.html#a2736894 @Bernhard: Could you confirm its ok to apply this patch? Looks great to me, but I'd like to have a design guy having it seen at least. Reassign as appropriate. Please, note that the second variant of the patch (mailed on Mar 26, 2011; 5:23pm - see above link) is wrong. It causes white background (see comment#11 in this bug report). You can use either the patch from Original Post on the maileng list (see http://nabble.documentfoundation.org/PATCH-Bug-35480-Curves-have-round-control-points-with-black-background-Draw-if-confirmed-tp2718487p2718487.html) or (better and more reliable - because you don't need to review it) just take the picture from hg.services.openoffice.org - here: http://svn.services.openoffice.org/opengrok/xref/DEV300_m106/default_images/svx/res/markers2.png Created attachment 47166 [details]
Draw screenshot with transparent Bezier handles
@ Thorsten: Sorry, I'm short in time, thus not as deeply involved in this bug to understand the underlying problem.
Here (LibO 3.3.2 on Ubuntu) I don't see the black background in Draw Bezier handles - see screenshot.
Is there an easy way for me to reproduce the bug and to verify the patch?
Disowning this bug until there is a clear way to reproduce/implement. Fix from Michael via commit 54c7480a6cdb049a5b0c907fa86af42068dcae16 to master - this was alpha channel lost somewhere in the code, not broken png. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 44645 [details] Screenshot See screenshot.