High Dpi workaround is in 1.7.2 . If you need to manually scale it for OSX and Linux, you can. You can also override the Windows guessing with your own scale, but hopefully that is not needed.
See the following for more info:
That’s it for now.
New version out. Main things are that we now use the better CSS support that was introduced in 3119+. I added things like options to wrap your content in a div with a class so you can have CSS like .myplugin .myclass {} etc. It still supports the legacy CSS for now, but that will be removed when the next ST beta drops.
Also supports templating in your HTML/Markdown content. You can send in template variables or configure your content template environment by changing the template tags or adding filters etc. Variables are available in both CSS and content under the plugin object, but the template environment options only apply to your HTML/Markdown content. I don’t need people mucking with the CSS environment 
.
For those who don’t like the idea of me tweaking the default popup/phantom css, I’ve added a sublime setting to turn off the base formatting. You will loose things like definition lists etc. Put you will have a pure ST formatting then. The default color styling CSS has been stripped down significantly to allow to let Sublime 3119+ generate CSS or let the themes specify the colors. But it can be overriden by creating a mdpopups.css in your user folder.
That’s the main stuff, you can see the release notes here https://github.com/facelessuser/sublime-markdown-popups/releases/tag/1.9.0.
Most of my plugins that use mdpopups will be updated to better use this stuff moving forward.
As always, let me know of any bugs.
Hello, I use the BracketHighlighter package that now require mdpopups 1.9.0, I run Package Control’s Satisfy Dependency command, but the version is still 1.8.0, how can I install the new version? Thanks.
I had the same problem this morning - I think Package Control’s dependency logic is flawed - my solution was just to go Packages -> Browse Packages, delete the mdpopups folder and restart ST, to force it to download the latest version.
@wbond I’ve got the same problems as stated above by @TheShrike and @kingkeith.
I’m on Win10 Pro x64 with ST3120 x64 portable. PC is v3.1.2.
I just freaked people out on old ST versions that were too old to even use hover events. I released a new BH to calm people down with a message explaining things. Also, I bumped mdpopups to 1.9.1. Had a bug in implementation. Anyways I’m going to bed .
Mine upgraded to 1.9.1 from 1.9.0 successfully after using Satisfy Dependencies 
(Win 7 x64, ST3120)
New version out 1.11.0.
The only change is that block code tags will no longer wrap. Inline code should still wrap.
New version out:
Released Nov 27, 2016
NEW: Mdpopups now handles CSS color names in color schemes.
Didn’t realize CSS color name support was added in color schemes. Be aware if you start putting CSS color names in your color scheme files, you may break plugins that are unaware that Sublime Text can do this. I didn’t even know this was possible until yesterday. Mdpopups will now support it, but I know I have other plugins that haven’t been updated to support this yet.
I’m sure when people are aware of this, there are going to be lots of color schemes that start using CSS color names. I am hoping I will have all my plugins updated by then to avoid people filing issues.
Please be aware that color schemes support named colors, but they are NOT the same as CSS named colors. Colors in color schemes are based on named colors from TextMate. green is very different between the two.
Some of the work that is going to be part of the next dev build fixes the bug that currently minihtml is using TextMate color scheme named colors for CSS named colors. This current behavior is considered a bug since we strive to follow the CSS standards, even if we don’t implement all features.
@wbond, So color schemes will always use TextMate named colors, but the CSS will soon use CSS named colors? Just making sure I understand.
Where can I find a list of TextMate named colors?
So apparently I misattributed the color names to TextMate. While TextMate uses them, and we support them since we support .tmTheme, they are technically X11 color names. You can see on that wikipedia page a summary of the conflicts between X11 and CSS. They appear to be a number of different versions of the color names with different capitalization and spacing. The page http://www.graphviz.org/doc/info/colors.html seems to have the same list as we support.
When I get around to documenting color schemes, I’ll be sure to list these, although generally the RGB hex colors seem more portable.
Thanks @wbond. This is exactly what I am looking for.
I agree that hex is more portable, and I would prefer everyone stick to those, but I have to be aware of them anyways as they are valid and when they are used by others it breaks stuff in some of my plugins.
Alright now using X11 color names:
Released Nov 28, 2016
FIX: Use X11 named colors and not CSS named colors in color schemes
Originally, mdpopups configured a lot of the colors of the popups and phantoms itself, but then Sublime added the ability for themes to specify colors for popups/phantoms and Sublime will autogen basic colors for themes that don’t supply popup and phantom CSS. It has become less important for Mdpopups to enforce color scheme colors, and instead let the color scheme and Sublime handle it. Because of this, some changes in how mdpopup CSS is handled have been made.
Plugins have a bit more power in overriding CSS (when they absolutely have to), but they should still use content wrapper classes and/or classes very unique to the plugin to allow a user to override any changes if they desire. Mdpopups won’t block plugins from behaving poorly, people will just have to file issues to the offending plugin’s issue tracker that has made it difficult to override their changes.
Released Nov 29, 2016
.
← Chang Logdefault.css anymore. User CSS rules just override default style rules.default.css can be disabled by setting mdpopups.default_style in Preference.sublime-settings to true.Finally pinned down something that’s been bothering. It appears that the default line-height (particularly on Mac) would cause odd things like periodic gaps between lines that were bigger than normal, and I believe slight image stretching. Default font was 1rem and line-height was 1.2rem. Reducing default line height to 1.1rem seemed to make these issues go away.
Released Dec 3, 2016