Rolf: 
ich kann das Problem nicht bestätigen. mein eigener Export (1.1RC4 de
unter WinXP) sieht sauber aus. 
Getestet mit 
- IE 6 / Shockwave Flash Player 5 
- Mozilla / Macromedia Flash Player 6,0,79,0

Das selbe Ergebnis unter Linux (Export mit 1.1RC4, angeschaut mit
Mozilla, Flash Player Version habe ich nicht)

Ich hänge meinen Export an den Issue.

Rolf/Christian .. könnt Ihr mein file ausprobieren und ggf. selbst ein
defektes erzeugen und anhängen?

Created attachment 9212 [details]
eported with 1.1RC4 on WinXP

Folgendes Verhalten:
1. Neuinstallation von RC4 (Workstation) und sofort Flash-Export
das Ergebnis ist gut (einzig die Nummern in den kleinen Seitenzahlen
sind teilweise schwarz ausgefüllt z.B. die "0" oder "6")
2. Dann verschiedenes gemacht unter anderem pdf-Export, neues
Textdokument geöffnet, etc.
3. Dann Flash-Export - Ergebnis -> nicht zugebrauchen.

Den Versuch habe ich zweimal durchgeführt (beim letzten Versuch "nur"
einmal Flash-Export nach der Installation und einmal pdf-Export
(Druckvorstufe) der Präsentation gemacht.
Bei dem nachfolgendem Flashexport: Ergebnis -> nicht zugebrauchen.
(beide Versionen des Versuches werde ich auf den Issue laden)

Mein Rechner: Suse 8.0 prof. 1200Mhz 1500MB RAM (unter KDE gearbeitet)

Das "Flasherzeugnis" von Andre sieht bei mir unter Opera6 (Flash5 und
6 installiert - weiß aber nicht welches benutzt wird) perfekt aus.

Created attachment 9214 [details]
gutes sxf nach Neuinstallation

Created attachment 9215 [details]
schlechtes swf nach einem pdf-Export erstellt

reproduzierbar.
Vor PDF-Export ist alles OK, danach kommt Murks. Wird die Datei
geschlossen und wieder neu geladen ist wieder alles OK.

Ich glaube nicht, daß der PDF-Export schuldig ist, vielmehr liefert
bereits der zweite swf-Export ein unbrauchbares Ergebnis.

Exportiert man zuerst nach PDF und generiert danach ein swf ist das
swf in Ordnung.

Also zum Reproduzieren einfach das swf zweimal nach Flash exportieren.
Der erste Export ist 1a, der zweite ist bereits unbrauchbar. Die erste
Seite geht gerade noch ("Welleneffekt" beim Text), aber bereits bei
der zweiten Seite fehlt der Text komplett, es sind nur noch die
Bullets vorhanden. (Die Seitennummern sind in Ordnung und die
Ãœberschriften zeigen den "Welleneffekt" wie die Titelseite)

Passiert übrigends mit dem englishen (preview) RC4 genauso..

short English translation:

Impress fails to export presentations to Flash if you try it a second
time. Text is missing or disturbed. See attached files (test.sxi,
test1.swf to test4.swf)

This seems to affect at least Linux systems, but not Windows.

Created attachment 9218 [details]
minimum presentation to show the problem

Created attachment 9219 [details]
1st export to flash

Created attachment 9220 [details]
2nd export in initial impress session

Created attachment 9221 [details]
export after restart of impress (ok, but not exactly the same as test1)

Created attachment 9222 [details]
2nd export in new impress session ... funny Charset now

Reassigned to Christian.

I can reprosuce the bug on Linux.
I can't reproduce it on Windows.
Please have a look

On Solaris I can reproduce the 'wavy' text after the export but not
the missing text.

Okay, had a look at that. The problem is limited to the *nix
platforms, because it's related to the FreeType fontcache. Since
freetype > 2.0.9, we seem to use FT_SizeRec objects as
FT_FaceRec-subsidiaries. This was AFAIK due to some heavy performance
and mem footprint probs, especially for CJK fonts. Unfortunately, this
breaks FreetypeServerFont::GetGlyphOutline(), because seemingly the
last selected size is used. This is correct for the first export (the
faces are newly created), but wrong for every subsequent one (the
cached faces are used, and the selected size thereon is arbitrary). If
I comment out bEnableSizeFT = (pFTNewSize!=NULL) &&
(pFTActivateSize!=NULL) && (pFTDoneSize!=NULL) in the FreetypeManager
constructor, everything is alright again. Only that this disables said
caching mechanism. The obvious fix, namely to call     

if( maSizeFT )
        pFTActivateSize( maSizeFT );

first in FreetypeServerFont::GetGlyphOutline, actually crashes my X
server :-(

To conclude, I don't know that code well enough to supply a valid fix,
especially not in a last-minute manner, without proper QA coverage.
Let's HDU have a look on that, I'd say.

thanks for the analysis...

*** Issue 19033 has been marked as a duplicate of this issue. ***

Fixed in CWS vcl7pp1r3.

*** Issue 20205 has been marked as a duplicate of this issue. ***

*** Issue 21177 has been marked as a duplicate of this issue. ***

*** Issue 21589 has been marked as a duplicate of this issue. ***

HDU->CGU: please verify in CWS vcl7pp1r3

change the resolution to fixed.

Verified in vcl7pp1r3 on Sols, Lin.

*** Issue 19478 has been marked as a duplicate of this issue. ***

*** Issue 23194 has been marked as a duplicate of this issue. ***

*** Issue 21589 has been marked as a duplicate of this issue. ***

The fix is integrated in OOo1.1.1 on Sols, Lin.
This version will be available soon.