Issue 50249 - ASSERTION: Error: File string.c, Line 240 - wrong textencoding during svm export
Summary: ASSERTION: Error: File string.c, Line 240 - wrong textencoding during svm export
Status: CONFIRMED
Alias: None
Product: Impress
Classification: Application
Component: save-export (show other issues)
Version: 680m104
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-02 16:55 UTC by IngridvdM
Modified: 2017-05-20 11:08 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
callstacks for the described scenarios (9.09 KB, text/plain)
2005-06-02 16:58 UTC, IngridvdM
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description IngridvdM 2005-06-02 16:55:32 UTC
There are two slighly different scenarios where I have problems with the above
assertion while streaming a GDIMetaFile to SvStream:

1)
a) Open an impress or draw
b) create a text shape with font 'Times New Roman' or 'Arial' for example.
c) Export the selected text shape as svm file
-> ASSERTION: Error: File string.c, Line 240

The assertion comes up because the given text encoding for
rtl_impl_convertUStringToString does not fulfill 'rtl_isOctetTextEncoding'
In the above example the textencoding is 65535.

2) While creating the ole object visual representation for the new chart I run
into the same assertion with a text encoding 9 which was set via uno api.
Moreover this new encoding is transported from the one MetaTextArrayAction to
all following actions in the while loop in method vcl/../gdimtf.cxx 'SvStream&
GDIMetaFile::Write( SvStream& rOStm )'. This might be worse?...


Call stacks attached.
Comment 1 IngridvdM 2005-06-02 16:58:37 UTC
Created attachment 26836 [details]
callstacks for the described scenarios
Comment 2 Marcus 2017-05-20 11:08:47 UTC
Reset assigne to the default "issues@openoffice.apache.org".