Apache OpenOffice (AOO) Bugzilla – Issue 14895
Flash export does not show "holes" in letters
Last modified: 2004-02-11 14:43:41 UTC
When exporting to Flash, the letters with "holes" (e.g. "o", "e", etc.) have their holes filled with ink color.
Created attachment 6427 [details] Screenshot of a Flash export
Created attachment 6428 [details] Test-case for the flash export
Created attachment 6429 [details] Test-case for the flash export
Created attachment 6430 [details] Result of the test-case export to Flash
Reassigned to Christian.
set to new
I change the target
Just to make sure that this works on Solaris and the Windows releases. Just a bug in the Linux release. Fixing this is probably "urgent" as a lot of Linux users do use OOo.
I can't reproduce the bug. Please have a look if you can reproduce it.
I have managed to succeed in reproducing the issue. OO1.1beta2 was installed from the download package you gave, and not from source, so maybe that's what makes the difference? I can vouch that it works on Windows platforms, but is generally broken on a RedHat 8/9 install, and a fresh Debian install. http://bytebot.net/bugs/Impress-Linux-1.1Beta2.swf <-- my example of the broken bit.
will have a look
I can confirm this problem in OOo 1.1 RC3 on Gentoo Linux. Additionally, some letters are smaller than others.
Created attachment 8603 [details] OOo Impress presentation testing different font types
I have attached a presentation file testing different fonts. It was made with OOo 1.1 RC3 on Gentoo Linux. It appears that the "filling-in problem" only occurs with non-TrueType fonts (lower part of the slide). The presentation I was looking at earlier had most of its text in "Times New Roman" (TrueType), but because this font was not available in OpenOffice, it was substituted by "Times" (not TrueType).
Created attachment 8604 [details] Screenshot of fonts demo in OpenOffice (Zapf Dingbats is not OK, the rest is)
Created attachment 8605 [details] Flash export of fonts demo: TrueType fonts are fine
Created attachment 8606 [details] Screenshot of font demo flash export: problems with non-Truetype and Zapf Dingbats
This explains why the problem does not occur in Windows. I don't know anyone who still uses anything but TrueType on Windows.
If we don't figure this out before 1.1 final, its going to look awful when people try it out. Or how do you propose we give a guide stating that "this is how you install TTF's on Linux"? It has an effect on RC3 which I'm using on Linux as well.
Created attachment 8797 [details] Bitstream vera works but non-TTF stuff don't
Confirm it to be with regards to a TrueType Font versus a non-TTF issue. The title is a TTF, whereas the other one isn't. I've used the Bitstream Vera TTF one, as a test. Bitstream vera sans (ttf) for the title, and Thorndale (non-TTF) for the remaining text.
Will this bug be fixed by 1.1 final release? We have converted all of our systems to Linux, but we still have to have one Windows machine running to convert the PowerPoint Presentations to Flash for us, and that seems to really bother the executives here to have to keep one server running Windows.
*** Issue 18703 has been marked as a duplicate of this issue. ***
In response to comments that this needs to be figured out before OOo-1.1, I agree. I filed a duplicate on this where I had problems in Linux, but not in Windows. The original power-point file was created on Windows using Times New Roman, but as this doesn't exist, OpenOffice is replacing it with Times even though I have Times New Roman install on my system and OOo recognises it. Surely if OOo is going to do this sort of font replacement then it should be required to handle it appropriately.
Set target to OOo 1.1.1 since its much to late for 1.1. Herbert, whats the difference with the broken fonts on linux? I think OutputDevice::GetTextOutline should always return the same kind of PolyPolygons
Probably the direction required by the "winding rule" is wrong for Type1's glyph outlines. I'm setting the status to accepted and will analyze it later...
I really think the font substitution issue is different. To fix it, make sure you do not have OOo running (shutdown quickstarter if you have it). Run Printer Administration (or, from a terminal, run spadmin) and, on the printer Properties button, look for the Font Substitution list and remove substitutions for fonts you have.
HDU->KA: Only the fonts where Bitmap::Vectorize() is used show the problem. Vectorize() has called because these fonts are only available as bitmaps and we need their outlines. When returning the PolyPolygon from the call please have the polygons conform to the winding rules "right winding -> filled" and "left winding -> open". Please note that the same effect also happens on Win32 when hollow glyphs from bitmap only fonts such as "Script" or "Modern" are converted to outlines.
*** Issue 20666 has been marked as a duplicate of this issue. ***
AW: HDU asked me to comment here and explain how to apply the winding rule on a PolyPolygon. The base problem is that the edge detector will not create winding rule PolyPolygons, it is only tracing edges. If someone needs to rely on that rule, he has to correct the PolyPolygons coming from VCL before using them (this is done from the 3d engine, too, e.g.). The problem now is that the VCL PolyPolygon as a data type does not have that functionality. Thus, this either needs to be done by whoever needs it, or (yes, tere is an alternative) the PolyPolygon3D needs to be used which has the disadvantage to be in svx and is specialized for 3d coordinates. There is a method called SetDirections() in two versions, one takes the normal of the PolyPolygon to know for which plane orientation to correct the PolyPolygon, the other calculates that normal itself. Maybe the best way is to take the implementation of PolyPolygon3D::SetDirections(...) and to simplify it for a VCL PolyPolygon. Just my 2 cents...
*** Issue 20617 has been marked as a duplicate of this issue. ***
*** Issue 20096 has been marked as a duplicate of this issue. ***
accepted
KA: Bug has been fixed, bugfix has been reviewed by THB
KA: bug has been fixed in CWS DRAW23
*** Issue 22897 has been marked as a duplicate of this issue. ***
Closed.
Issue was closed by mistake. Reopened.
Reassigned to me for verification.
Set to fixed.
Verified in CWS.
Tested in internal master. Issue closed. Thanks again for your help.
Reopened to integrate fix into SRC680 MWS.
Reassigned to person who fixed this bug.
Can we set the target to 2.0 now to get rid of this fixed issue in 1.1.1 when querying for 1.1.1 bugs to solve?
Changed target milestone to OOo 2.0. Fix has been integrated to OOo 1.1.1 already.
KA: verified in CWS draw23master
fixed
CGU: Cloned the task for integration in OOo2.0 Id of the cloned task is issue 25370 I close the issue