How to find a "visual center" of a bunch of text?

I've a drag and drop functionality, so that the whole text could be dragged and dropped as per the writer's/user's convenience on a canvas.

I'm using draftjs for the editor. So I know everything I need to know about the individual text pieces (blocks). For example, I know that the above text has 9 blocks of text. I know the character length of each block. I know the width of each block of text using getBoundingClientRect.

I want to be able to figure out a visual centre (approx. the white circle in the image) out of the shape that the text blocks make, so that when the user drags the whole text on canvas afterwards, the hinge point of the text drag be that visual centre.

It's easy to find the vertical centre of the whole text, but it's difficult for me to find the horizontal visual __centre. I've tried taking

Half of the longest character length block of text, really silly to do, since one block of text could be very long, the next one really short.
Average, silly again, doesn't work.

Responses(2)

Personally, I would approximate it to a rectangle — combined height of all the blocks being the length; and the longest width block being the breadth ... the centre of the rectangle then, would be the hinge.

Notwithstanding the computational complexity, arriving at a solution for finding the exact visual centre of the polygon formed by the text, for this use case, feels a bit overkill.

Having said that, Mapbox has developed an algorithm for finding the visual centre of a(ny) polygon.

blog.mapbox.com/a-new-algorithm-for-finding-a-vis…

The corresponding library is called polylabel. (so named because the problem they were trying to solve was to find an optimum place — a.k.a. "visual centre" — to place a label inside an irregularly shaped polygon)

However the work remains on your part to calculate the coordinates of the formed polygon, to be passed to polylabel like so:

const polygon = [[x1, y1], [x2, y2], [x3, y3]];
const centre = polylabel([polygon]);

You're right! polylabel's "main" use case deals with polygons in maps.

Apart from having exterior boundaries, polygons in maps can also have (multiple) interior boundaries (say: two lakes inside a city ... you would have a polygon representing the boundary of the city, and two polygons representing the boundaries of these lakes)

The polygons in GeoJSON notation take this into account; and they are represented as an array of "regular" polygons (which in turn are arrays of coordinates representing the boundary points):

- Polygon
  - LinearRing (exterior)
    - Positions...
  - LinearRing (interior)
    - Positions...
  - LinearRing (interior)
    - Positions...

{
  "type": "Polygon",
  "coordinates": [
    [ // co-ordinates representing a single ring/boundary
      [0, 0], [10, 10], [10, 0], [0, 0] 
    ],
    [...], // more "boundary" polygons...
    [...],
    ...
  ]
}

Excerpted from this treatise — macwright.org/2015/03/23/geojson-second-bite — on GeoJSON notation

cc: gdad-s-river

P.S.: If you you were to use a GeoJSON polygon, then the expression for evaluating the visual centre would just be this: polylabel(geoJSONCoords). In fact the first argument that polylabel accepts as per the docs, are polygon coordinates in GeoJSON format.

I think you have to decide on the rules you want to use to define the visual center. I agree that the white dot is a good approximation.

The vertical center is the line as shown by Sai's answer. However, I don't know that that is visual center. There are 9 lines of text, which would ordinarily put line 5 as the center. However, line 1 appears to be about 2x the normal height which would put the center between lines 4 & 5. The reason I bring these things up is because the center of the polygon around the text may not always correspond to the visual center.

Visually speaking, the left hand side of the text forms an obvious alignment marker. The right hand side does not have such a clear reference point. I would instead describe it as a suggestion of the end.

The visual presentation of _dieeeee _marks it as an anomaly and so instead of defining the end point, it merely influences the end point. The ends of wait and back are relatively consistent, which strongly suggests they form the right hand boundary.

Given all these factors, I would have to spend some time experimenting with the rules. I would consider the space each character in a line occupies in addition to the over all length of the line. I would make the same considerations for vertical spacing as well. If the majority of text is a consistent font/size/color, then anything outside of that would have to be considered.

The way I would address this (assuming I was building some sort of widget or tool), would be to take lots of samples, analyze them individually, building my rules as I went along - and hoping for something that reaches 80% success.

Or maybe the approach that Sai suggests is the 80% success rate.

Thread

How to find a "visual center" of a bunch of text?

Responses(2)

Recent threads

Search Hashnode

How to find a "visual center" of a bunch of text?

Responses(2)

Recent threads