Resize images pasted from webpage to width of page if it exceeds that size

Many users in our office copy and paste from webpages into LibreOffice Writer. We’ve noticed that when the page contains an image that is wider than the page in Writer, the image is truncated instead of resized.

How can we configure Writer to resize large images, rather than truncate them?

Here is an example webpage:

That page has a single image, which is truncated when pasting into LO Writer.

Note that we need to configure LO Writer, not retrain users, as there are too many users to retrain and consequences too high if one makes a mistake. Often checking each page for images is tedious and error-prone. I’m trying to avoid user complaints of “that other office suite doesn’t require us to tediously check every image and image…”.

I don’t understand. When I paste the example image, it is automatically resized to available width between margins. If I change afterwards the margins of the page format, yes, the image doesn’t adapt to the new context. So, edit your question (please, be friendly, keep all relevant data at this stage in a single location; don’t use a comment or, worse, an answer) to explain your users procedure. Mention OS name, LO version and save format.

Here, Fedora Linux 36, LO 7.3.6.2

EDIT (after @Grantler’s comment): I pasted only the image as it seemed OP’s question focused on this.

@dotancohen1 - your example is correct.




This behaviour happens if text and image are inserted from clipboard. I often was angry about that. My current proceeding is this: I select only parts of websites, containing pure text or single image.

In your case you could

  • proportionally resize the image by using the right bottom handle (to width of text area)
    or
  • cut out the image and insert (as a bitmap - paste special) again and it will be in proportional size within the text area
  • To select the image and apply “Original Size” does not work sufficiently, because the width is transformed to width of text area but the height remains (i.e. no proportional resizing).

Probably a feature request at Bugzilla could help on the long run?

1 Like

Sorry. Can’t confirm this with LibO V 7.4.2 under Win 10. The actual behaviour if I try to insert the “wide graphic” above the words “This confusion” I actually get confusion: The inserted image is not actually truncated (see below). It’s also not resized as needed to the available space as Writer commonly does in many cases. The property editor shows the size as if adaption to the space between the margins was made (in my case 17 cm) and the unchanged height (11.3 cm), and the view of the image is truncated this way, but the handles for manual adjustment show the correct original width. If I use the handles to reduce the width (keeping aspect ratio) everything seems to work just fine.
This is obviously a malfunction, but I lack the detailed knowledge about graphic formats and about embedding images into web pages to judge if it

  • is abug of LibreOffice
  • is a bug of some browsers
  • is a bug of the software used for the web presentation
  • is a vicious trick applied by someone misusing incomplete specifications to aggravate Copy/Paste.

Appending:
What @Grantler reports should be evidence for a very strange bug in Writer. But it’s also obvious that the original size isn’t regarded in the web page, and that there may be conflicts between supposed standards and supposed specifications applicanle in different environments. .

2 Likes

I can’t have the users now selecting every element of the webpage individually! That would be more tedious than just pasting and then checking everything.

I’ve filed a feature request here:

https://bugs.documentfoundation.org/show_bug.cgi?id=151992

Thank you.

1 Like

This page has the image that has specific dimensions specified in HTML:

The absolute width value of 1058 should be honored by Writer on HTML import; and automatic resize here would be incorrect. With standard 96 PPI resolution (that should be assumed on import), this gives about 280 mm.

1 Like

Thank you for noticing that. Other elements with explicit widths that exceed the Writer page, are infact resized. Content divs are a good example. I would state that any element wider than the Writer page, should be reduced in width. Images specifically should be reduced in height to maintain aspect ratio.

There’s no width attribute for div element in HTML AFAIK. And if Writer ignores some element’s properties on import, it’s a matter of incomplete support of that external format, so a bug, not a feature.

You are correct, I should have said “the width CSS property”, not “attribute”. That said, the point is that certain elements do contain width instructions, which are properly ignored when translating an HTML document meant for display in a web browser to a document (ostensibly) meant for printing.

You can try the extension PicTool

Thank you. We need a solution for configuring LO beforehand, not fixing the issue afterwards.

We all may dream our dreams.
There is an issue clearly, but there also are probable conflicts concerning our expectations how it should be fixed.

In such a case you surely have staff actually knowing something about the technical context. One of them may use my very raw sketch of a routine for the needed repairs below to get something better adapted to the actual needs.
To learn how to call a routine of the kind by a ClickOnaButton after pasting shouldn’t require too much of a retraining.

Sub changeAnchorFromAsCharToToParaAndReduceOversize()
doc = ThisComponent
cCtrl = doc.CurrentController
dp = doc.DrawPage
For Each obj In dp
 If obj.supportsService("com.sun.star.text.TextGraphicObject") Then
  With obj
   asz = .ActualSize
   sz = .Size
   If (.AnchorType=1) AND (sz.Width>17000) Then
    .AnchorType = 0
    sz.Width = 17000
    sz.Height = sz.Width/asz.Width * asz.Height
    .Size = sz
   EndIf
  End With
 EndIf
Next obj
End Sub

Only on self-interest I tested on MS Word2010: Same results as in Writer.

On Web Layout “better” result (image not truncated) - In LO Writer’s HMTL document (Menu File | New | HTML Document) the same “better” result.




It seems that the given problem (preformatted images) is not that easy to solve for text processing apps in general… :wink:
For other text imports from the internet I often use paste special :: unformatted. But it seems hard to apply this on images because of the right “density” in ppi/dpi, see @mikekaganski’s comment. - Cheers

1 Like

Terrific, that alleviates that avenue of resistance. Funny how nobody complains about MS Office, but the same behaviour elicits responses in LibreOffice.

Nice, thank you. I would simply add the paste to the beginning of that routine, such that it replaces the paste action instead of supplementing it.

It’s going to boil down to me to fix, so I’ll save that very raw sketch for when I have a few hours to budget for learning the syntax and experimenting.

Thank you.

That very raw sketch wasn’t exactly raw under some relevant aspects. It mainly lacked an attempt to determine the available width. Now there is a demo also containing a function doing that for the standard case. See attachment:
disask83957adjustGraphicsPastedFromHtmlPage.odt (119.0 KB)

I don’t like to tamper with clipboards, nor am I a great friend of dispatcher commands. That’s the reason for what I chose the “supplement-way”.

1 Like

Thank you.

I’ve downloaded the file and opened it in a safe environment where you can’t steal all my secret documents )). Even though I’ve set the Macro settings as low as possible (in this safe environment) the macro returns no signs of having done anything - whether I run it from the toolbar or the Tools menu.

I’ve opened the document in LO Writer 7.4.2.3, copied from Alan Storm’s terrific website (even though the document already has the relevant portions pasted in), then pressed the toolbar button. No response. Did I forget a step?

Thank you!

Very strange. The code works as expected for me. However, …

  1. (A) There was a forgotten useless line of code. (It didn’t any harm.)
  2. (B) Trying to reproduce and trace your issue I found a strange behaviour of Writer
    blocking the correct treatment of an object needing it in our context if this object is individually selected in advance. I added a line of code to avoid the problem.
    I now attach the reworked example file (mainly made to steal your secrets, of course).
    disask83957adjustGraphicsPastedFromHtmlPageSlightlyReworked.odt (119.1 KB)
1 Like

I apologize for taking so long to get back to you.

This new macro works!

I very much appreciate your patience in helping to resolve this issue. I’m going over the macro code right now - it is very straightforward though I am not familiar with the LibreOffice macros. I’m not sure from whence ThisCompnent is defined, I suppose it is a global, and I have no idea what objects are defined on it. So going over your code gives me a terrific head start on what to start searching for.

I suppose that With makes the object’s properties available directly from the dot operator - that’s an interesting language feature that I’ve never seen.

Again, thank you!