The original post titled "My Workaround for Sizing Images Inside Markdown Tables" provided an adequate workaround for making images in Markdown tables appear (more or less) at their intended sizes. However, the workaround didn't go far enough since different front-ends use different dimensions for displaying posts. This sequel post intends to address that inconvenience.
Banner for Cover Image was composed using HTML and CSS, with light edits made using MS Paint.
Screen captures of Markdown tables come from the post "Testing Markdown Table Images Using Ecency" at #Ecency.
Logo for Cub Finance (CUB) comes from cubdefi.com. Logos for Bitcoin (BTC), Ethereum (ETH), Litecoin (LTC), HIVE-Backed Dollars (HBD), and Hive (HIVE) come from Cryptologos.cc.
Different front-ends render posts differently. This is true for LeoFinance and for Ecency. Normally this is not a concern since the differences are usually stylistic or cosmetic. However, these differences are crucial when it comes to showing images inside Markdown tables (especially if the tables feature cryptocurrencies and their logos).
Below is a composite image of screen captures I took of the original post as shown by front-ends for LeoFinance and Ecency:
From the image, it can be seen that LeoFinance shows posts in a tighter space than Ecency. This is due to two reasons:
Explaining the details behind the way each front-end displays content is beyond the scope of this post, so I leave that task for other fellow Hivers. My concern is fine-tuning the workaround I proposed in the original post.
Fixing the column width by using a long string of identical characters works, as far as it goes. However, the front-ends display images dynamically. Even using the IMG element from HTML to hard-code width and height wasn't enough to set the image at a size of our choosing.
However, the discrepancy in image sizes shown in the composite image gave me two ideas to pursue here:
The principle of the workaround is sound; it just needs to be generalized to handle any front-end (or most of them, anyway).
As a carryover from the original post, I will stick with the poker diamond, the ♦ character:
| Method | Code | Output |
|---|---|---|
| Windows Character Map | ♦ | ♦ |
| Alt-key combination (make sure [NumLock] is on!!) | [ALT]-[4] | ♦ |
| HTML Character Entity (name) | ♦ | ♦ |
| HTML Character Entity (Decimal) | ♦ | ♦ |
HTML Character Entity (Hex)-- notice the x before the digits | ♦ | ♦ |
How you enter this character for the long text string is up to you.
♦s to Each Column To Adjust Image SizesThe previous post showed that the workaround works with the LeoFinance front-end and any front-end which operates in a similar manner (PeakD? Maybe, I don't know).
Since the workaround broke when Ecency was used, I will test it using Ecency. Since I use LeoFinance to publish this post, I will use a screen captures of the tables as shown in Ecency:
From the screen captures, it can be seen that each time the right column increased in size, the other columns decreased in size accordingly.
For LeoFinance, only 14 ♦s were needed for the images to be sized properly inside the Markdown tables. Due to the greater space available with Ecency, 22 ♦s were needed, and the 22nd ♦ introduced the horizontal scroll bar. 21 may have been enough, but the CUB logo would have appeared a bit smaller than logos for BTC and HIVE.
What would happen if I made the changes only to the right column while leaving the other columns alone?
♦s Only to the Right Column To Adjust Image SizesThe column sizing held after I deleted the string of ♦s from the other 2 columns. Even the horizontal scrollbar disappeared.
Does the string of ♦s need to be in the right column? Is it OK to put it in any other column while leaving the remaining columns alone?
♦s Only to the Left or Middle Column To Adjust Image SizesThe column sizing failed when I used either the left column or the middle column. On top of that, the larger images appeared larger than intended. I expected the column sizing to adjust no matter which column was fixed with the string of ♦s, but that's not what happened.
So it looks as if we only need to focus on the right column when we place the string of repeated characters.
Can this workaround be extended to larger tables, such as a 6-column table?
(Before I make that test, I will say that based on what I had seen in the original post, it would be best to make sure that the images are roughly the same size. If most images are small but one is massive, the massive image will throw off the table.)
Now for testing the 6-column table.
The first 4 columns were resized for images to fit properly in the Markdown table, but the last 2 colummns show images smaller than expected. That's not what we want.
This works as expected: All images are sized properly. The smaller cells grow larger thanks to the longer strings of ♦s. Can the strings be removed from the first 4 columns without breaking the other 2 columns?
The right column (for CUB) was properly sized, but Column 5 (for HBD) shrunk more than expected, which caused the HBD logo to appear smaller than desired. Will a string of ♦s fix that problem?
Success!
| NOTE: |
|---|
| This workaround works with large images needing to be used in tables. If the image is tiny or small to begin with, nothing happens to those images. If all images are tiny or small, there is no reason to use the workaround; save it for large images. |
Poker diamonds were my choice for testing purposes. For an actual post, use any character you want. "Invisible" characters can be used, but don't use whitespace characters such as SPACE or TAB since HTML will take strings of whitespace characters and collapse them into one whitespace characters. (This is what happens if 2 spaces are typed after the period of a sentence; HTML collapses those 2 spaces into 1 space.) Whitespace characters are part of the regular character sets we use; while "invisible" characters are found deeper inside Unicode character sets.
If "invisible" or whitespace characters are too much trouble for the workaround characters such as dashes or underscores or equal signs can work.
If the table looks clumsy with only a couple of columns having these workaround strings, then include them in all columns for a consistent appearance.
Different front-ends display posts differently. The LeoFinance front-end uses a tighter display space with margins and a vertical scrollbar. The Ecency front end uses a wider display space. Markdown tables take advantage of whatever space is availble.
Just as web pages display the same web page differently, Hive Social front-ends do this with our posts-- especially with the Markdown tables we include in them. This means we need to make sure the Markdown tables look good in Ecency even though we publish the post from LeoFinance.
It turns out that we don't need to use the workaround with every column. All columns are sized automatically, but one or two determine the space used by the others. The revised workaround takes advantage of this detail by using the workaround string only in the columns which look off, and these will be toward the right end of the table.
Once the columns are sized properly, additional workaround strings may be added not for functionality but rather for visual appeal.
| Links in image | URLs |
|---|---|
| Daily Crypto Markets Live Blog | https://leofinance.io/@leomarkettalk |
| LeoFinance | https://leofinance.io |
| TheTerminal | /created/hive-101265 |
| Hive Projects | https://hiveprojects.io |
| Dust Sweeper |  @dustsweeper |
| Dust Bunny |  @dustbunny |
| Links in image | URLs |
|---|---|
| "...to make up for..." | https://leofinance.io/hive-167922/@magnacarta/who-is-magnacarta-and-why-is-he-sending-me-pizza |
| LeoFinance | https://leofinance.io/@magnacarta |
| Proof of Brain | https://proofofbrain.blog/@magnacarta |
| ♦ D.Buzz-only ♦ D.Buzz: ♦ at-magnacarta.buzz | https://blog.d.buzz/#/@magnacarta.buzz |
| Festivus | https://festivusweb.com/index.php |
