GNOME Bugzilla – Bug 704391
Incorrect text placement and wrap in GNM_SO_PATH_TYPE
Last modified: 2018-05-22 14:01:25 UTC
Gnumeric hangs on opening a fuzzed gnumeric file. I waited 90 minutes and killed gnumeric. By the time 4GB of RAM was used. Git versions of glib, goffice, gnumeric, libgsf and libxml2. Test case: http://jutaky.com/fuzzing/gnumeric_case_18956_2522_hung.gnumeric Program received signal SIGINT, Interrupt. 0x00007ffff3b2d06c in g_hash_table_lookup_node (hash_table=0x8d0b60, key=0x7fffffffd650, hash_return=0x7fffffffd618) at ghash.c:374 374 while (!HASH_IS_UNUSED (node_hash)) (gdb) bt
+ Trace 232255
-- Juha Kylmänen Research Assistant, OUSPG
Not a bug, I think. This sheet sets up an insane style for a large range, A0:XX65536 (where XX is whatever code column 1024 gets). The style is a conditional style "(Überstunden!B1=7)" with a relative cell reference, so the style of each of 64M cells depends on the value of 64M different cells. That, well, is going to take a lot of time and memory. It would be intersting to have a look at the original file to see if we import it correctly.
The original file used in fuzzing was http://www.excelmexel.de/HTMLOOCalc/Zeiterfassung.ods converted to a gnumeric file. I think Gnumeric places the yellow notes' text incorrectly if compared to LibreOffice. Also I noticed that in conversion to xls Gnumeric loses the yellow notes while LibreOffice's xls version still has them.
The file from comment 2 does indeed open with the text that was supposed to go into the yellow rectanges places elsewhere. And the file takes forever to open, although that may be my debug build.
I don't see that in the odf file. So either I am misunderstanding something or we are misimporting something.
For me opening the ODF file of comment #2 takes about 80 seconds. While that's not fast, I would not call it excessively slow. That ODF file does not contain any large conditional region. Is suspect that that may be a result of the fuzzing later on. I do get conditional regions on most sheets, but none of them exceeds 40 cells. Regarding the placement of the text: The text is part of the rectangle objects. It is not placed separately. Since the rectangles are placed correctly. the objects in question are placed correctly. I do note that some words are missing in the text. For example on Kalendar, the blue text should start: "Aufgabe:\n Erzeugen Sie"... So we seem to read or store the text incorrectly.
The rectangles are saved as custom shapes: <draw:custom-shape table:end-cell-address="Kalender.E26" table:end-x="1.864cm" table:end-y="0.32cm" draw:z-index="0" draw:name="Text Box 1" draw:style-name="gr1" draw:text-style-name="P1" svg:width="7.528cm" svg:height="7.519cm" svg:x="0.81cm" svg:y="0.027cm"><text:p text:style-name="P1"><text:span text:style-name="T1">Aufgabe:</text:span></text:p><text:p text:style-name="P1"><text:span text:style-name="T2">Erzeugen Sie in Spalte A einen Kalender von diesem Monat und lassen Sie die Sonntage mit roter Schrift darstellen.</text:span></text:p><text:p text:style-name="P1"><text:span text:style-name="T1"/></text:p><text:p text:style-name="P1"><text:span text:style-name="T1"/></text:p><text:p text:style-name="P1"><text:span text:style-name="T3">Hinweis: Die Aufgaben in den Blättern</text:span></text:p><text:p text:style-name="P1"><text:span text:style-name="T3">Kalender, Anwesenheit, Pausen, Überstunden, Sonntagsarbeit, Summen , Gesamt bauen aufeinander auf und sind in dieser Reihenfolge zu lösen.</text:span></text:p><draw:enhanced-geometry svg:viewBox="0 0 21600 21600" draw:type="mso-spt202" draw:enhanced-path="M 0 0 L 21600 0 21600 21600 0 21600 0 0 Z N"/></draw:custom-shape>
Note that this may also be related to bug #704417.
I have fixed the problem with the text import. The fact that the text is shown partially outside the does not look like an ODF import issue!
We clearly fail to correctly place and wrap the text associated with a GNM_SO_PATH_TYPE.
Text wrapping is now fixed.
Created attachment 249463 [details] screenshot The attached screenshot shows two issues: 1) The text should either be top and left aligned or vertically and horizontally centred. It is neither. 2)We probably should keep some margin to avoid the text to run into the lines.
Text alignment should work now. Actually, we do have margins, just they are set to 0.
Created attachment 249550 [details] screen shot text is cut off on the right..
I can't reproduce the cut off. Did you update both goffice and gnumeric?
Yes, both goffice and gnumeric are up-to-date and I can replicate the cut-off text problem.
Note, cut-off only happens on-screen. It does not happen in the print preview.
Created attachment 249587 [details] Screenshot This is what I see on screen. The preview code is quite different, and was copied from the rectangle/ellipse file which is affected by the same size issue.
The print preview should now be correct (there might be some differences occasionally because the font metrics are not exactly the same and because the layout width might be slightly different when printing (by about 1%).
Anything left here?
Created attachment 249739 [details] screenshot This screenshot shows the difference between print preview and on screen with current git for both goffice and gnumeric. Note that the text on screen is partially cut off.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/227.