Have you figured out how to size images using Hive-flavored Markdown? Do images inside Markdown table cells look off even when using the HTML IMG element with its attributes for width and height? Although I haven't arrived at a working solution to this problem, I may have found a workaround we can all use when we include images in Markdown table cells. Below is the process I used to come up with my workaround for sizing images inside Markdown tables.
Banner for Cover Image was composed using HTML and CSS, with light edits made using MS Paint.
Screen captures of Markdown tables come from #Ecency.
Logo for Cub Finance comes from cubdefi.com. Remaining logos come from Cryptologos.cc.
Hive-flavored Markdown-- as much as I have checked ove the last several months-- doesn't provide a way to size images either smaller or larger. There could be a way to do that using a modified URL (a URL which includes characters such as ? and &), but I don't know what that would be.
In theory, the IMG element from HTML can be included in Markdown code. Not only can the IMG element be included in Markdown, the width= attribute and height= attribute of the IMG element can be used to show an image at the proper size within the Markdown.
This is true when an image is loose in a post or a comment. If the image is still large at the hard-coded size, then the front-end will resize it on its own for viewing in a post or comment.
So what happens when an image is to be displayed inside a Markdown table? This is where many hairs have been lost and many chins scratched to the point of turning red.
I'm still looking for a fool-proof way to show images at sizes I want rather than at sizes the front end chooses for me.
I may have found a workaround which will work in many situations involving Markdown tables. It's not 100%, but I found out where it won't work and I can explain why it won't. Oddly enough, it depends on text-- specifically, a long-enough piece of text.
| My Workaround |
|---|
| Either in the column heading or in a data cell-- your choice-- place a piece of text long enough where it can determine the width of the column. |
Since many words can be long, the piece of text has to be so long that the front-end will use this piece rather than some random word in the data cell to size the column.
For uniformity, one character should be repeated enough times to make this piece of text. For the purposes of this post, I chose 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.
It should be a straightforward thing to do to get images sized as needed, yet the Hive front-ends are funny things in that regard. Below are tests I made to see how well the workaround works.
The CUB image is small. The HIVE logo is much larger. The BTC logo is just as large. The Hive front-ends will display the BTC and HIVE logos just wide enough to fill the width of the post or comment. They are shown as loose images as a point of reference for the rest of this post.
How will these images appear inside table columns?
| Bitcoin | Hive (or is this Hive Blockchain?) | Cub Finance, Hive's cousin crypto living the DeFi Life on BSC |
The front-ends used by Hive Social automatically resize large images to a size small enough for use in a table cell. For images small enough to fit onto a table cell as-is, they are left alone.
What happens if a long string of repeated characters is used in each column?
♦'s (Using Small CUB Logo)| ♦♦♦♦♦♦♦♦♦♦♦♦♦♦ | ♦♦♦♦♦♦♦♦♦♦♦♦♦♦ | ♦♦♦♦♦♦♦♦♦♦♦♦♦♦ |
All 3 columns are resized to fit the string 14 ♦s (14 poker diamonds). For the BTC and HIVE columns, the images shrink to fit the string. With the CUB column, the column becomes larger to accommodate the 14 ♦s while the image itself stays as-is.
♦'s (Using Large CUB Logo)| ♦♦♦♦♦♦♦♦♦♦♦♦♦♦ | ♦♦♦♦♦♦♦♦♦♦♦♦♦♦ | ♦♦♦♦♦♦♦♦♦♦♦♦♦♦ |
The columns are the same size here as in the previous case with the small CUB logo. However, the larger CUB logo shrunk in size to fit the column as defined by the 14 ♦s.
Does this work if the table's data cells contain text people care about, text for actual reading?
♦'s and Text in Data Cells| Bitcoin | Hive (or is this Hive Blockchain?) | Cub Finance, Hive's cousin crypto living the DeFi Life on BSC |
The 3 columns are resized based on the length of string of 14 ♦s.
What happens if 10 ♦s are used instead of 14 ♦s?
♦'s (instead of 14 ♦'s) and Text in Data Cells| Bitcoin | Hive (or is this Hive Blockchain?) | Cub Finance, Hive's cousin crypto living the DeFi Life on BSC |
The last column-- featuring the CUB logo-- is resized to fit the string of 10 ♦s, but the first 2 columns take up the remaining width of the table and split that width 50/50. Even then, the BTC and HIVE logos appear larger than they should be.
| Observation: |
|---|
| It's not enough to use a long string of characters to determine the column size to be used by large images. The long string of characters needs to be long enough so that the images appear (more or less) the same size. This means the long strings of text needs to (more or less) match the width of the images. Adjust the long strings of text as necessary to achieve a balanced appearance. |
What happens if the HTML IMG element is used instead of the Markdown code for images?
♦'s and Text in Data Cells| Bitcoin | Hive (or is this Hive Blockchain?) | Cub Finance, Hive's cousin crypto living the DeFi Life on BSC |
This is the most puzzling of the experiments since theHive front-end's behavior overrode the width= and height= attributes of the IMG element.
This also shows that when it comes to Markdown tables, there's no advantage in using the HTML IMG element. Sad, but true.
However, in every other way the behavior of the columns which use the IMG elements is the same as for those tables using Markdown code for images. I can repeat the above experiments to modify them to use IMG tags, but the results will be the same in each case.
What happens if the table is expanded to include 6 columns instead of 3?
♦'s and Text in Data Cells| Behind the Scenes; Elements; Simple data values; Cosmetic features; Merged cells for data entry; Named Ranges | Formulas and Functions | Conditional Formatting and Potential Improvements | Column 4 | Column 5 |
The images were resized as needed, but the string of ♦s wasn't long enough since there are words longer than the length of the string of ♦s. The string of ♦s needs to be longer than the longest word appearing in the table. If the table uses the logos with numbers such as prices and percentages, then it's not an issue.
If the images still look off, increase the length of the string of repeated characters. At this point, it's trial and error, but the fix is quick.
Any character can be used for this workaround. A good number of characters exist as HTML character entities (named or hex or decimal) for drawing boxes or lines or other things such as playing card suits.
There are even a few "invisible" characters which can be used. When making the table, use a visible character for make your measurements, and after the table looks right replace the visible character with the invisible character of your choice. Just don't use a whitespace charcacter such as a tab or a regular space since HTML will collapse them into a single character.
It should be trivial to use a resized image inside a Markdown table at Hive Solcial, yet it's anything but that. If anyone out there knows how to include size attributes for the Markdown codes for images (or if there is a way to encode the width and height of an image into a URL), please leave a comment explaining what how to do that.
Until such assistance arrives, I arrived at a workaround which relies on a long text string made using the same character repeated as many times as necessary. This long text string must be longer than the longest word used in the data cells of the table.
The workaround works with large images to make them appear smaller in the Markdown table. Small images remain virtually untouched by this workaround. If all images are large, the workaround will show them at the right size. If all images are small, the text in data cells will determine the column widths in ways which look unappealing. A mix of large and small images is not advised; as the saying goes, "Go big, or go home."
Until I find the perfect solution, or the correct way to use Hive-flavored Markdown to handle image resizing, this workaround will get the job done in mose cases.
| 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 |