{"id":104,"date":"2018-10-29T19:35:11","date_gmt":"2018-10-29T19:35:11","guid":{"rendered":"https:\/\/stuff.tamius.net\/sacred-texts\/?p=104"},"modified":"2019-11-23T20:20:29","modified_gmt":"2019-11-23T20:20:29","slug":"how-to-make-speech-bubbles-draw-themselves-a-story-of-pain-part-1","status":"publish","type":"post","link":"https:\/\/stuff.tamius.net\/sacred-texts\/2018\/10\/29\/how-to-make-speech-bubbles-draw-themselves-a-story-of-pain-part-1\/","title":{"rendered":"How to make speech bubbles draw themselves: a story of pain (part 1)"},"content":{"rendered":"

Every now and then, I sit down in front of my computer and start making a comic<\/a>. It follows a very similar premise to DM of the Rings<\/a> and Darths&Droids<\/a> \u2014 that is, take a movie (in my case, How To Train Your Dragon) and pretend it’s a D&D session \u2014 except my work is much less original and not that good, probably. Oh well.<\/p>\n

If you’re making any sort of comics, you’ll probably have to draw a ton of speech bubbles. Mind, drawing basic speech bubbles isn’t that hard: you use the oval selection tool, select an area and fill it with color. But boy does it take time. The more of them, the longer it takes \u2014 and boy do some pages feature a lot of them.<\/p>\n

\"\"
Just to illustrate how bad it can get. Now admittedly an episode normally won’t have this many bubbles, but that doesn’t mean drawing speech bubbles isn’t a colossal waste of time.<\/figcaption><\/figure>\n

Because we like to work smarter, not harder, the question pops up: why don’t we make a script that would draw speech bublbes for us? I’m using GIMP anyway, and GIMP has plugin support. \u2018\u2018This shouldn’t be too hard,\u2019\u2019 were the famous last words as I opened visual studio code on that day about two weeks ago and got to work.<\/p>\n

Drawing rectangles is easy. Drawing ellipses is hard.<\/h1>\n

Comics often use two kinds of bubbles: there’s bubbles used for narration, which are often rectangular; and there’s bubbles used for speech, which are generally elliptical (more or less).<\/p>\n

Determining borders<\/h2>\n

If we want to draw any kind of bubble (be it rectangular or elliptical), we must first figure out where to place it. This is the easy part, because:<\/p>\n

    \n
  1. we use GIMP and put the text for each bubble on its own, separate, transparent layer. That’s one of the important assumptions that we’ll make (especially for elliptical bubbles): we don’t<\/em> reuse text layers for more than one bubble, and the layer is always transparent except for text.<\/li>\n
  2. images and layers are, in general, grids of squares (pixels), where each square is colored with a different color. This allows us to borrow some tricks from Ultrawidify<\/a>: we’ll check every pixel of every row, and every pixel of every column for the presence of non-transparent pixels.<\/li>\n<\/ol>\n

    If we keep track of where the first non-transparent pixel was found for every row and column, we can figure out where the text starts and where it ends. If rows of text don’t overlap each other, we get the bounds of every<\/em> row of text in the layer. And when we know that a row of text starts at line 32, ends at line 64, starts at column 3 and ends at column 125. That gives us 4 corner points per line of text, and that’s enough data to draw a rectangle. The vertices are at 3, 32; 125, 32; 3, 64; 125, 64. The procedure is so simple it doesn’t even deserve its own heading (although there is a few minor, seemingly simple improvements you can make to that). At least compared to what’s about to come.<\/p>\n

    Ellipses can honestly piss off<\/h2>\n

    Do we even know what we’re trying to do?<\/h3>\n

    Yes, actually. We want to draw an ellipse around a set of points, where:<\/p>\n

      \n
    1. All the corner points must be inside or on the edge of said ellipse<\/li>\n
    2. Points must be as close to ellipse edge as possible<\/li>\n<\/ol>\n

      In order to draw an ellise, we need to know:<\/p>\n

        \n
      • width and height of the ellipse<\/li>\n
      • center of the ellipse (or more accurately, upper left corner\u00b9, but we can get that from width and height of the ellipse)<\/li>\n<\/ul>\n

        \u00b9In computer graphics, the coordinate system is flipped over horizontal axis compared to the coordinate system used most everywhere else.<\/small><\/p>\n

        because those are the parameters GIMP’s ellipse selection tool takes. We already know the points that represent the edges of text. What we need to do is to take those points (bunch of pairs of x,y coordinates) and somehow convert that to parameters of the ellipse that will satisfy the two rules outlined above.<\/p>\n

        Computers are very good at two things: logic and maths. This means we need to tell it how to calculate the center, width and height from those points. Because I don’t recall that lesson from my math classes, I went to every programmer’s best friend (stackoverflow) and discovered that \u2014 spoiler alert \u2014 this is either a) more or less impossible or b) requires diploma or master’s degree in maths.<\/p>\n

        I studied computer science. We had maths, but not that kind of maths.<\/p>\n

        Time to cheat<\/h3>\n

        First of all, we subtly change our second requirement. We don’t require that the corner points are as close to the edge of the ellipse anymore, instead we focus on trying to draw the smallest ellipse possible. It’s less than ideal, but we’ll have to live with that.<\/p>\n

        \"\"
        It’s a subtle difference that only matters in edge cases like this. ‘Points as close to the edge as possible’ will give us a bigger ellipse overall, which is sometimes desired (if the upper portion of the speech bubble were to be covered with something). ‘Smallest ellipse’ produces lots of wasted space around the bottom line.
        Dots serve as a rough illustration of what the script would consider to be a corner point of the text.<\/figcaption><\/figure>\n

        After we’re done revising our requirements, we head back to google and look up the equations for the ellipse.<\/p>\n

        x = a * cos(t)
        \ny = b * sin(t)<\/i><\/div>\n

        Where x, y<\/em> are coordinates of a point on the ellipse; a, b<\/em> are the length of the primary and secondary radii. We can do something with this. We can calculate where the center of ellipse will be. We just calculate where the middle point of every opposing pair of corner points is (e.g. the opposite point of upper left point in the top line of text is the lower right point in the bottom row of text). Since each pair of corner points may give a slightly different center, we take the average of those centers. Now that we know where the center is, we can use some high school maths to calculate the angle between straight line from center to a given point and the horizontal axis, and we do that for every point. Biggest ellipse will contain all the points, and we will have our answer.<\/p>\n

        Except t<\/i> is not the angle to our point.<\/b> t<\/i>is the angle between horizontal axis and the point where our point would be, if the ellipse was squished (or stretched) into a circle. We can squish (or stretch) ellipse into a circle by multiplying (or dividing) one of the coordinates with the aspect ratio of the ellipse.<\/p>\n

        Do we know the aspect ratio of the ellipse? No.<\/p>\n

        We know the topmost point of the top line of text, we know bottommost point of the bottom line of text, we know leftmost and rightmost point of the longest line of text. We can get width and height from that. We can use that to calculate an aspect ratio.<\/p>\n

        Is that aspect ratio the same as the aspect ratio of the ellipse we want? Tests concluded that no. This is not the aspect ratio we’re looking for. Our final result looks something like this:<\/p>\n

        \"\"
        White ellipse is what the script did. The selection has same dimensions than ellipse, but is placed roughly where the ellipse is supposed to be. Red lines represent what our script considers to be a line of text.
        Red line should be entirely within the ellipse (with at least 3 pixels to spare in the vertical direction, and 7 pixels to spare in horizontal). But the red seems to poke out for some reason.
        And not only does the ellipse fail to contain the lines completely, it’s also offset to the left and a little bit to the right.<\/figcaption><\/figure>\n

        Can we fix the aspect ratio with some brute force? I could write another paragraph on how this was attempted, but long story short: turns out we can’t. We’d need more data to draw the ellipse we want.<\/p>\n