Feature Request: Image rendering, pixel image offsets

This is a feature request to add x and y offsets to iTerm2's image rendering. For example, an xoffset value of 50 would draw the image 50 pixels from the left of windows and a yoffset value of 100 would draw the image 100 pixels from the top of the window.

This allows you to have more control over image positioning in scripts etc. We need this feature to implement better image positioning in neofetch. Neofetch is a script that draws an image next to information about your system using w3m or iTerm2's image rendering. We're currently trying to implement x/y offsets to the iTerm2 image mode to be consistent with the w3m mode.

The only way to pad images that I've found is to use spaces but this is very inaccurate as everything else works with pixels.

Thanks!

• iTerm2 version - 2.9.20160311-nightly
• OS version - 10.11.3 build 15D21

cc @dylanaraps

NOTE: edited to fix typo, a y offset of 100 should draw image at 100 pixels from top, not 50

How would you know what offset you want? Wouldn't you need to know how large a cell is for this to be useful?

We do know the width of each character cell

Oh, are you asking for the window size in pixels with OSC 14 t and dividing the the number of rows and columns? That's not very reliable (it gives the window size, not the session size, so split panes will throw you off).

I should add a proper interface for this.

Commit b8a0c705 adds a new sequence:

You send: esc]1337;ReportCellSizeesc\

iTerm2 reports: esc]1337;ReportCellSize=height;widthesc\

The height and width values are floating point (e.g., 12.0). For now they happen to be integers but that may change in the future. In your application, rounding to the nearest integer ought to do the job.

The next question is how to handle the various size modes when you specify an offset.

Pixels: You might specify a size that's equal to the image to keep it from scaling. We can expect you're able to do arithmetic, so you should increase the size by the offset if you give an offset.

Percentage: You probably want to use half the screen or 100% of the screen. The space occupied should not change when an offset is given.

Cells: You probably want to know how to draw around the image and you need it to be predictable, so the space occupied should not change when an offset is given.

Auto: n/a

In other words, we'll never adjust the amount of allocated space when an offset is present; the image will still use the same number of cells but possibly become smaller.

The Percentage discussion makes me think this should be an inset on all four edges, not a simple offset.

Commit 244ebf43 adds support for image insets. Add insetLeft, insetRight, insetTop, and insetBottom, optionally. They default to 0. The must be between 0 and the cell size. It is scaled proportionally when the font size changes.

Status changed to closed

The restriction that the inset be less than one cell wasn't necessary and I removed it in commit da2a2d97. If you use an inset then the aspect ratio will not be preserved, which is not really awesome. This needs more work.

Status changed to reopened

Milestone changed to Feature Complete 3.1

Milestone changed to Feature Complete 3.2