Confirnmed with 1.1.2 (1.1.1 was still ok)

Oh no... This problem also comes with the Cut problem. 
 
Under KGhostView 3.2.2 (Ghostview 0.20) the sentence is cut in the 2 word. 
http://zcn.cdedicated.com/oo/bug1.png 

Additions checking: 
Checked under OO 1.1.2 : 
http://zcn.cdedicated.com/oo/check.pdf 
 
Results (weiird): 
- Under KGhostView 3.2.2 (Ghostview 0.20): 
  http://zcn.cdedicated.com/oo/bug2a.png 
Seems to be perfect isn't it? 
 
- Under Kpdf 0.3 (Kde 3.2.2) : 
  http://zcn.cdedicated.com/oo/bul2b.png 
Here's the bug.. All reversed... 

Should be noted-  
All my tests were performed using Xpdf and the Culmus fonts  

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

eyalbens: I am not sure I understand how the issues you see are related to this
report.

They sound more like a dup of issue #21271

cp->hdu: the pdf looks fine in acroread. I have no idea about the "split in two
words" thing. Please have a look

Please check again with the original PDF (on
http://planet.nana.co.il/kamberd/OOo1.pdf) since this is the only PDF here that
was written with type1 fonts (eyalbens's file was written with a ttf font).

Checked again, the bug is there (Acrobat Reader on Windows XP)

Dotan- for the 2nd time: the issue that you are talking about is NOT the same
issue that this report is about.

Remember- one report, one issue. This report is about parentasis from type1
fonts getting reversed on export to PDF. other PDF export problems belong in
their own report, NOT HERE, where they are confusing everybody.

The problem on the unix platform is a duplicate to issue 23202 which has been
fixed in CWS vcl7pp1r4 for target OOo1.1.3. The problem on the Win32 platform is
probably related to issue 10218, but I'm not too sure. I cannot reproduce the
problem on Win32 with a recent SRC680 build?

Sforbes- Thaks for the valuable lesson and please raed your mail for additional
comments in this regard.

OK, I've used different fonts than Dotan, so my bug isn't related to this 
subject, sorry ... 

Checked it on OOo 1.1.3 (under linux) and the bug is yet there (now it is masked
on first attemp with a bug regarding OOo using English font for puncuation in
Hebrew text)
To reproduce
1. Type an RTL hebrew text that includes parenthesis
2. Choose "Select All" (or Ctrl+A)
3. Set the fonts to TYPE I (eg. Nachlieli from Culmus)
4. Export to PDF.

My language settings- http://planet.nana.co.il/kamberd/OOo113.png
when setting the document to Naclieli-
http://planet.nana.co.il/kamberd/OOo113%2D2nd.pdf
When setting the font to Lucidasans-
http://planet.nana.co.il/kamberd/OOo113%2D3rd.pdf

Ooops. I found it. Fixed in CWS fontlists04.

reopening for reassingment

reassigning

HDU->US: please verify in CWS fontlists04

It doesn't seem to work for me. Worse, glyph fallback seems to be broken. 
us->hdu: pls .contact me. Thx.

.

If I understood well from debugging into this, we fall back to "Times New Roman"
with glyph fallback, which isn't too bad. Unfortunately "Times New Roman" is
only an alias to "Nimbus Roman No9 L" on JDS, which doesn't contain any hebrew
glyphs. Thus my bugdoc almost displays anything.

This reveals that a font on the glyph fallback list is chosen which is
considered to have a lot of glyphs, but without actually checking if this font
provides any of the required glyphs.

Either this is simply too expensive in terms of performance or it is forgotten(?).

US->HDU: pls. explain. Thx.

Other than from the encoding we don't know the unicode coverage of an X11
font..., so there is sometimes no glyph fallback, especially if the X11 font
claims that it covers all of iso10646-1.

HDU->US: please verify in the rebuilt of the fontlists04 CWS
I already submitted the followup issue 36490

.

US: the additionally encountered glyph fallback issue is fixed in the new
release of 'fontlists04' cws. But the original problem -reversed brackets- is
still visible. Sorry.

.

HDU->US: Since the CWS fontlists04 is too important for Beta and the GF problems
that were fixed for this issue are very important too, we shouldn't remove the
task from the CWS. I suggest to submit another followup issue.

.

Filed follow-up (clone) task (issue 36691) for this issue as the original
problem with reversed brackets with Type1 fonts on PDF export remains under
certain conditions.

Verifying this one though, as we'd like to integrate some crucial fixes
regarding glyphfallback on PDF export done with this issue.

Verified on MWS m78.8875.

Bug remain in m79

Regards
Dotan

I can reproduce the bug: OOo 1.9.79, Mandrake 10.1. 

@dotan, shlomif: pls. read. This issue experienced a shift. 
In this task we fixed some requirements (glyphfallback on PDF export with Type1
fonts).

The original problem remains (see my comment from Nov. 4) and is now issue 36691.

PLEASE KEEP THIS "FIXED/VERIFIED" ISSUE CLOSED! 

Otherwise you keep on blocking OO.o 2.0.

Explanation: 

OO.o 2.0 (as well as the beforehand released ReleaseCandidates) can only ship
with a certain amount of open issues on the corresponding target. The directive
is to ship a release with zero bugs. Hence everyone is asked to limit the amount
of issues with target OO.o 2.0 which are assigned to him. And of course this is
controlled. 

Thus reopening this issue without need surely delays the release and forces me
to take some extra time and action on it which I simply don't have at the moment.

Closing Fixed/Verified issue again.

Adjusting Summary to reflect the changed subject of the issue.