By "wrap left" do you mean "wrap before"?
Is this one bug report or several?
If several, you must split all issues to their own reports.

Please include numbered reproduction steps with each step on its own line.
Please also include screenshots of the problems.

Your explanations in the description are presented in a confusing way and are not enough for anyone to confirm the issues.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.

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!

I do not get the problem visible in usgs_tut_2_st_pauls_error.png when I save usgs_tut_V_0.doc and reload.
Image wraps remain as "before" and anchor "to character" like in the original.

Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit)
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: fi-FI (fi_FI)

(In reply to johann from comment #2)
> 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.

Do I understand you correctly that these companies expect to benefit from LibreOffice without investing anything to its development? If yes, this is unfortunate and an unsustainable approach.

This bug tracker contains over 7000 identified bugs, mostly triaged by unpaid volunteers. Any non-profit or for-profit entities can thus easily assess what known issues would affect them and prepare by hiring developers to fix them: https://www.documentfoundation.org/certification/developers/

Created attachment 118987 [details]
Package including all the doc files + png with the error

I downloaded the doc + the image showing the error and zipped them up.

re: comment #3

comment #3 addresses non-profits getting a "free ride". in the U.S., we do not have an omnipresent national government that tackles social ills with a horde of governmental workers and programs affecting every level of society. this work is "farmed out", mostly, to quite small non-profits directly connected with the local community they serve. it might be somewhat understandable to say that the organizations should be made to pay to get LO working, but that is not what the document foundation intends.

it is, perhaps, not expected that all developers are fully tuned into the objectives set out for LO.
please see this link from which the quotes, infra, were extracted (the first item of the "mission statement"):
http://www.documentfoundation.org/foundation/

"Manifesto
"Our values
"We commit ourselves: 	
"to eliminate the digital divide in society by giving everyone access to office productivity tools free of charge to enable them to participate as full citizens in the 21st century
	
"We reject:
"the ownership of office productivity tools by monopoly suppliers which imposes a de-facto tax on global electronic free speech and penalises the economically disadvantaged"

the issues of this bug are core as it relates to supplanting MSoffice which is what these some 1,000 lowly-paid users currently use. is a small non-profit going to go out and hire experts to make LO usable for themselves? NOPE!

if you were talking about some obscure italian local government, yes i would expect them to have to invest time and money to circumvent the 7,000 LO problems.

for further edification of developers and readers, please note the following.

it is **NOT** the policy of LO that every end-user firm -- irrespective of the redeeming nature of their contributions to society without profit motives -- must somehow individually find the money and expertise to contribute to fixing LO. clearly, such a policy is socially untenable. the proper LO policy would be to happily contribute to the greater good by acknowledging that these non-profits cannot make the same resource contributions that commercial and governmental operations can and should make. according to LO's 'Manifesto', that is exactly what LO intends.

these non-profits operate on grants/contracts that are re-imbursable by expenditure. can you imagine that they are going to submit a proposal to the U.S. government that says '$3,000 to fix LibreOffice so we can use it". moreover, do you see the U.S. government saying "sure, that sounds good"? if you do see this happening can you live with the Federal retort: "we will just take that off the line item 'hot meals for economically and physically disabled shut-ins'"?

additionally, how would LO ever hope to make inroads into the seven-figures worth of contractors and grantees that have mandated Federal interchange requirements based on MSoffice if LO cannot compete in that arena? what about all the state, regional, county, and city governments? i realize competing with MS is a big and probably thankless task. however, the work has to be done to make LO a premier product. it just cannot be done on the backs of those that cannot afford to contribute as has been wisely acknowledged in LO's official policy statement, supra. i can understand a developer not familiar with LO's policies feeling that anybody getting a "free ride" is not right and demeans their work product. the contrary is true. a developer's work is even more valuable by virtue of its contribution to the betterment of the social fabric offered via the small non-profit setting that diverts dollars from payments to soft-ware behemoths to their sole goal of supporting the disadvantaged in society.

mind you, i understand the 'open-source' approach and applaud stances such as the EU has taken to avert soft-ware hegemony and anti-competivity of the sort which MS used to sink navigator with ie and as google chrome has done to opera and will do to firefox in order to save the billions of $US they used to pay for search connections.

re comment #3 confined to bug discussion

the reason i did not pre-crop the image externally as with all the other images is that i was testing to see what would happen.

the problem with the referenced image is two-fold. when it was in-memory it was cropped left/right and scaled to a size roughly, in printable inches, of 3.7 W x 4.2 H. the anchor was 'paragraph', not 'character'.

when it came back (such as you saw when loading from the on-disk file) the cropping values were much smaller (making the width larger), the anchor had been changed, the anchor values all re-stated from the original paragraph values, and the scaling did not yield the original size.

this is the nexus of this problem: on-disk files are not representative of in-memory attributes.

"hot-key" usage for access to menu items: 'Format' --> 'Image'

for the few billion potential LO users from the asia/pacific region, turning on the 'Asian phonetic guide' menu option might be desired. if so, the hot-key sequence 'Alt-o-i' gets you this menu option since it is the first menu option keyed off the character 'i', and will not go down to 'Image' also keyed off of 'i' and beneath that option.

since image formatting in current usage must predominate amongst users, getting the 'Asian phonetic guide' maintainer to change the first character-key option to something else seems sensible and guarantees that the very fast 'Alt-o-i' sequence remains going to image formatting.

I am aware of the sad "starve the beast" economic policy that started to gain ground sometime in the 1970s in the U.S. Yet, the U.S. remains the richest country in the world and its citizens are thus uniquely positioned to make things happen, whether with government or private funds.

100% compatibility with .DOC files is a very hard problem. It is a binary file format unlike the newer .DOCX. More about the problem: https://en.wikipedia.org/wiki/Doc_%28computing%29#Specification

There are few experts currently among the active developers able to improve .DOC support, perhaps only one. However, there are other ways to contribute besides hiring expensive professionals.

The quality assurance team does work that makes it faster for developers to tackle bugs. If only a quarter of the 1,000 users you mention would test one bug report per month, we would be on a whole new level. I'm thinking about perhaps using a single Bugzilla account, not subscribing to bug mail, skipping any difficult reports. I am always ready to guide new bug triagers, even if there are 250 of them.

This is a good read on the realities of the project, from a U.S.-based TDF board & QA team member: https://joelmadero.wordpress.com/2014/10/11/user-expectations-and-the-reality-of-our-community/

yes, the U.S. has the largest GDP in the world and China is second. neither the workers i have mentioned nor the farmers in Xian province are participants in any of that "wealth". in fact, over 80% of the executive directors -- the highest paid on staff -- are paid less than the **average wage** for their area ... not nearly the wage they should be paid for their level of responsibility. the lowest paid workers -- the ones i mentioned -- are paid only slightly above minimum wage.

i am certain if you re-read my comment #7, you will find yourself having no trouble understanding what is at issue there.

the 1,000 some people i have referred to are bare-bones users to which comment #7 would have no meaning at all. most of what they do is "fill in the blanks" on government forms and prepare memos. their level of app usage fully precludes their being of any help sorting out bugs. of the 300+ firms i would guess that there are less than a couple dozen people with the expertise to comprehend comment #7. however, if LO "out-of-the-box" does not work for them, there is no incentive to spend their precious time trying to make it work with absolutely no guarantee that that time will ever come.

your offer of help is well appreciated, but this group is incapable of addressing LO's backlog of bugs.

now as to .doc: none of these firms are without the ability to use the xml variants. in fact, just a few months ago i surveyed what formats they were using and found that only a handful of state and county forms were exclusively .doc. of course, these could be converted for internal usage, but then there is the re-export problem when they submit documentation and reports if LO cannot save correctly in the .doc format. so, if LO were fully working with .docx/.xlsx/.pdf things would be pretty good; but there remains some export problems. it seems a shame that the only solution i see for that problem is using third-party software to take the xml back to the old format.

it is a further shame that after the many years of development of star-/open-office that .doc compatibility has never been fully implemented. and now, essentially, you are telling me that such compatibility actually is never going to happen via LO.

everybody passed on LO.

however, you might note that whoever marked this as 'needinfo' ignored the wealth of commentary explaining one of the many problems we encountered in day-to-day usage of LO that prompted the lack of desire to implement LO at all.

thank you,

johann

Ok, great, let's close.