https://bugs.documentfoundation.org/show_bug.cgi?id=94126
johann <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |UNCONFIRMED Ever confirmed|1 |0 --- Comment #2 from johann <[email protected]> --- five (5) days ago i prepared the files not marked 'NEW' for your perusal, infra, and they are available at the base: http://forthepolls.org/pub/LO/ usgs_tut_2_st_pauls_error.png --> NEW usgs_tut_V_0.doc usgs_tut_V_0.pdf usgs_tut_V_0.txt usgs_tut_V_0.xhtml usgs_tut_V_1.doc usgs_tut_V_1.pdf usgs_tut_V_1.txt usgs_tut_V_1.xhtml usgs_tut_V_2.doc --> NEW at the time 'V-0' was in memory and had all the correctly displayed formatting. 'V-1' was loaded from the on-disk copy of 'V-0' into a second copy of LO for that output. as you will see, V_1 preserves the essence (it changes what you put in to its own equivalent and this is clearly confusing) of the formatting of images (all originally wrapped 'before' from the 'right paragraph border' and at or spaced 'from the top'). EXCEPT when the image is cropped and then it sets new crop dimensions, ignores the 'keep scale' check-box, sets new image dimensions, and scales on the foregoing (in section IIII.1; it is the only such image not cropped pre-insertion). see 'usgs_tut_2_st_pauls_error.png', supra, for the 'V_2' containing-page returned for this image. i am not about to explore the over 405,000 bytes more in the .xhtml file from the in-memory V_0 v. the output from the on-disk file from V_0 re-loaded into V_1. obviously the memory images are radically different and one more indication that what LO saves to disk is not what users are seeing and why re-loads are not persisting formatting previously done in memory. that was then and now is another story. this morning i got back to this project and was editing 'III' and added another image. after the usual "toing" and "froing" from project to dialogue that LO unnecessarily requires of users to get scaling and positioning of images correct, i was double-checking using the print to display facility and returned to editing and saved. then LO apparently went into a loop and did nothing more than display the saving progress bar at the bottom. trying to get it to escape i applied a memory scavenge to it which returned successfully, but the loop continued. i then tried an execution priority change, nothing. then i paused it and i continued it, nothing. then i tried to remove it entirely and somehow explorer.exe went haywire (possible a memory leak by LO?) and i could not access anything and had to re-boot. 'V_2' is the recovered file (minus the unsaved image addition at LO failure). i originally was using 'title page' formatting, but i discovered that neither word nor LO itself (on re-loading) recognizes this "feature". So, i went to the regular page formatting with an exception for the first page. in the on-disk file (post-LO-failure) re-loaded into LO ALL page formatting was lost and the result was a mushrooming of 20 pages to 30. you can refer to my original submission, supra, for the description of what happened to the wrap-formatting of the images. i was asked by an organization of non-profits that numbers over 300 firms (with an average number of office-type users of 3-4 each) to check out openoffice and libreoffice and i started with LO due to the perverse cross-licensing that impedes openoffice from gaining access to LO software, but not the reverse. thus, assuming LO would be more up-to-date and have better release testing, i expected something more closely aligned with the word/excel functions this organization's members REQUIRE. these firms exchange word, excel, and pdf formats back and forth with Federal, state, and local governments which are effectively 100% 'ODF' unaware and that is not going to change any time soon. they also source documents extensively with chart/image inclusions and need to produce "letter-press" output all the time. so LO must be picture-perfect in doc/xls, docx/xlsx, and pdf or making inroads with ANY firms that do business with such governments or have similar requirements is a total non-starter. aside from the normal inertia resisting anything new, LO faces eliminating millions of U.S./Canadian firms with tens of millions of users that have similar governmental and/or [inter-]business requirements. this leaves very small "island" firms that are using MSoffice totally internally available to LO **IF** LO at least gets bugs like this one squashed. you can add my own personal requirement and that is SVG 1.1 (1999) standards compliance across all modules. no SVG actually precluded my finishing this project in LO. since this is about 'image' insertion, SVG-related belongs in this bug because SVG does not work in LO writer. for this evaluation i chose a personal project with no due date and no specific format. both conditions are fortuitous since normal expectations of completing the project would be out-the-window with the problems encountered with LO. is this bug and its attendant problems going to prevent LO adoption? YES! -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
