Warning I ended up writing a lot. I hope some of it makes sense and is even correct. Its late, but this is how I've always viewed the subject of token sizes. :) First off I like these tokens. Second on the subject of padding to make them square. Square isn't automatically the best way and even square you need to think about where to place the token in the square padding. In the middle or in a corner. Here is an example using one of your tokens I screen captured. The red box around it is simply to show where the padding is. The base I added to further help show the size of the fig compared to a unit and where the centre part of the fig is in most game terms. The top two are the same, figure placed in the centre with enough padding to make the base end up exactly one unit (so the figure is 2x2 units even though in game terms its one unit in size. So if the user wants the token to be one unit in size they make the token 2x2 in Roll20. 2 units in size would be 4x4 in Roll20, etc. The problem with this method is the snap to grid. The top right token shows where the token will be when you drag it around and let go. The top left token shows how you would want to place it, in roll20 the user would hold the "Alt" key while moving the token so it won't snap to grid. This method will rotate nicely around the true centre of the figure's body which is nice for games that need facing or users who like to rotate their tokens to show the direction they are facing. The bottom left token shows the figure placed in a corner of the overall padded token. For sizing this works the same as the top tokens. For snapping to the grid this works without having to hold the "Alt" key and manually place on the grid. Rotation works as long as you do it in multiples of 90deg, anythig else and the snapping to the grid is a mess. This is because Roll20 performs the snap to grid on the unrotated token and then rotates it. The user will once again have to use the "Alt" key to place it on the grid. The bottom right token behaves exactly the same way as the bottom left, but can only be rotated 180degs and still snap properly. But it has one slight advantage over the bottom left and the top tokens. It "gets in the way" less. With less transparent padding it won't get selected by the user as much when trying to select another token next to this one. In Roll20 if the token is above another token and you click on the transparent padding of this token to try and select another token next to it you will select the top most token. The user ends up moving this token to the back or moving it out of the way so they can select the other token they want. Also graphics dragged onto the Roll20 table top are sized differently when dragged from the art library vs from your computer. Dragged from the art library they always default to 1unit in my experience. So the user has no way to know what size this figure was intended to be and they need to make a decision on that. If its a large creature then typically that would mean 2x2 units. Medium just one unit, etc. This is the reason why a figure dragged from the art library that is not square would look squished or wrong. The figure might be 100x70 pixels. Roll20 puts it in a square unit (70x70 pixels) and now the figure looks squished. And this brings us to our next problem. That is the "native" pixels per inch of Roll20 is 70 pixels. If you are designing a figure that is the typical 1 unit in size, lets say a human that takes up 5' of space. You don't want to design the graphic at only 70 pixels, you probably won't get much detail in the graphic. So you probably design your figures at a higher pixel count than that. But if you don't design them at a multiple of 70 pixels per inch, the token will not be sized correctly in relation to the scale of the tabletop and the user will have to resize the figure manually until it looks about right for them. And from then on move the token around with the "Alt" key because the token would not be exactly a unit in size. If you make your graphics in multiples of 70 pixels then the token can be resized to fit 1x1, 2x2, 3x3, etc. and it should be the right size figure for the scale (5'/unit?). So a halfling put on the table top at 1 unit would look a lot smaller than a human put on the table top at 1 unit without the user having to resize the token manually to make it look right. Some disagree with this philosophy, I think Devin Night tried this and users rebelled if I remember right because the goblins and other small figs were too hard to see, but this is how I would want all my figures. They should be the right scale when placed and sized in grid units. So what's the best way to create tokens? Probably the best people to ask are others that are creating tokens so everyone does them similar whatever method they use. I don't make tokens, except to resize other's tokens to my liking, but in my opinion you should try and design the figures to be inherently square to begin with so you don't have these problems. Of course that is a problem with fighters with a great sword, monsters with tails, guards with spears, etc. I think users just have to place odd sized figures with the "Alt" key and there is no way to get around it. Just try and keep the odd sized figs to a minimum. But I would always make the figs in a multiple of 70 pixels. So if I was making a typical human that would end up 1 unit in size (70 pixels), but I wanted to design with more detail than 70 pixels would give I would do it a 350x350 or 420x420. With the way Roll20 works this also helps when at increased Zoom levels. Roll20 actually uses your higher pixel count for higher zooms so the increased detail is not wasted. For odd shaped figures I'm leaning to the bottom examples above, but then if dragged from the art library the user would have to resize the figures from 1 unit square, but in full multiples of units. The key to me is multiples of 70 pixels so the figure fits on the grid in units and scaled the actual size they should look when at those units.
