Bug 128559 - [FILEOPEN Keynote] wrong text direction (RTL)
Summary: [FILEOPEN Keynote] wrong text direction (RTL)
Status: NEW
Alias: None
Product: Document Liberation Project
Classification: Unclassified
Component: libetonyek (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected
Depends on:
Blocks: Apple-iWork RTL
  Show dependency tree / graph
 
Reported: 2019-11-02 19:25 UTC by Pablo
Modified: 2024-08-03 09:15 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Attachments
Keynote presentation with RTL text (247.24 KB, application/vnd.apple.keynote)
2019-11-02 19:25 UTC, Pablo 		Details
PDF exported from Keynote (12.36 KB, application/pdf)
2019-11-02 19:25 UTC, Pablo 		Details
screenshots of a the file displayed with KeyNote... (496.44 KB, application/zip)
2023-12-05 08:59 UTC, osnola 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Pablo 2019-11-02 19:25:04 UTC 
Description:
Title from Keynote imported with text direction LTR instead of RTL

Steps to Reproduce:
1. Open the attached Keynote presentation
2. Compare the colon position with the attached PDF exported from Keynote

Actual Results:
Text direction is LTR with colon on the right.

Expected Results:
Text direction RTL with colon on the left.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.3.2.2 (x86)
Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL
Comment 1 Pablo 2019-11-02 19:25:31 UTC 
Created attachment 155473 [details]
Keynote presentation with RTL text
Comment 2 Pablo 2019-11-02 19:25:49 UTC 
Created attachment 155474 [details]
PDF exported from Keynote
Comment 3 Xisco Faulí 2019-11-04 11:49:48 UTC 
The file attached can be open since libetonyek was updated to version 0.1.9 < https://cgit.freedesktop.org/libreoffice/core/commit/?id=c6e73f3e5bfd5b1cca94f985b5299857d0238ae3 >

@David Tardon, I thought you might be interested in this issue...
Comment 4 osnola 2021-09-21 13:28:30 UTC 
Just for information, I just add some code in libetonyek to retrieve the right-to-left writing-mode in a text's zone which must solve this problem.
Comment 5 Pablo 2023-02-08 22:03:53 UTC 
Still reproducible in:

Version: 7.5.0.3 (X86_64) / LibreOffice Community
Build ID: c21113d003cd3efa8c53188764377a8272d9d6de
CPU threads: 2; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-IL (en_IL); UI: en-US
Calc: threaded
Comment 6 Eyal Rozenberg 2023-12-04 21:36:44 UTC 
Nitpick regarding the attached example: Are you sure HelveticaNeue-Medium is supposed to have Hebrew glyphs? Also, few people have that font installed I think, so it's better to use a more popular cross-platform Hebrew font, like one of the Culmus ones.

Anyway, reproduced with:

Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 516f800f84b533db0082b1f39c19d1af40ab29c8
CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: he-IL (en_IL); UI: en-US
Comment 7 osnola 2023-12-05 08:59:41 UTC 
Created attachment 191239 [details]
screenshots of a the file displayed with KeyNote...

A screenshot of the file opened in KeyNote and of the informations on Helvetica Neue Medium displayed by Font Book. 

Under OsX, each font is free to define as many unicode characters as it wishes. Currently, libetonyek only retrieves the font name stored in .key, .pages, ... files and the unicode characters.