I think there are two slightly different issues here!
1. SVGs generated by Mermaid use the SVG 2 features, but other than browsers, most libraries only support SVG 1.1 features, i.e. <https://github.com/mermaid-js/mermaid/issues/2102>, which is what the other comment mentioned.
2. Mermaid requires a browser layout engine to render the diagrams (your issue), i.e. <https://github.com/mermaid-js/mermaid/issues/3650>. This is something I also really want to fix (I maintain the [`mermaid-js/mermaid-cli`][1] project and we need to use Puppeteer/Headless Chrome to render mermaid diagrams, which isn't ideal.) However, I don't think this would be easy, since we'd need a browserless tool that supports a browser-like layout engine (although I'm hoping that [Servo][2] might eventually be able to support it).
And if you do want to do headless renders of Mermaid diagrams, I'd recommend using (or adapting, since the code is all MIT licensed and I'm not aware of one that uses Selenium):
> A file that contains characters organized into zero or more lines. The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the <newline> character.
So, if you have some non-printable characters like BEL/␇/ASCII 0x07, that's still a text file.
(and I believe what bytes count as a valid character depend on your `LC_CTYPE`).
But the moment you have a line longer than {LINE_MAX} bytes (which can depend on which POSIX environment you have), suddenly your text file is now a binary file.
Kind of a weird definition indeed. One edge case: the definition states the file must contain characters, so presumably zero length files are out. But then how could you have zero lines?
Yes obviously. But the POSIX specification for a "text file" as above is that it contains characters, which an empty file by definition does not. So an empty file cannot be a text file if you read that specification strictly, and therefore you cannot have zero lines in a text file. As soon as you have a single character there is at least one line, and the amount of lines can only stay the same or grow from there.
The definition should read "one or more lines" instead or (probably better) specify that a text file contains "zero or more characters".
I was at Fukushima Daiichi on Monday, and they explained that they only want to take a few grams of the melted material to test the composition of the melted fuel/debris, e.g. what elements are in it.
Even just planning to remove all of the melted fuel is a long way away.
I can't remember if they were talking about Unit 1 or Unit 2, but from what I understood is that due the collapsed rubble above/around the reactor, they only have a very narrow opening, which means they've struggled to use larger robots.
And I believe the robot operating centre is a bit of a distance away from the reactors too (probably so that the robot operators don't need to wear protective equipment).
> What they need is a sort of "anteater-tongue machine" that just will try each crevice until finding the correct path.
I think the problem is that once you get through all the debris, there's a big cavern. Hence why they're using some sort of crane robot on a rope (it reminds me a bit of a [claw machine game][1]).
Weirdly, enough, golang is one of the only programming languages that actually has built-in support for a cross-OS config dir location: [os.UserConfigDir()][1].
I don't really ever program in golang, but whenever I write a Node.JS/Python tool that does need a user-global config file, I just write my own implementation of it:
function userConfigDir() {
switch (process.platform) {
case 'darwin':
return `${os.homedir()}/Library/Application Support`;
case 'win32':
if (process.env['APPDATA']) {
return process.env['APPDATA'];
} else {
throw new Error('%APPDATA% is not set correctly');
}
case 'aix':
case 'freebsd':
case 'openbsd':
case 'sunos':
case 'linux':
return process.env['XDG_CONFIG_HOME'] || `${os.homedir()}/.config`;
default:
throw new Error(`The platform ${process.platform} is currently unsupported.`);
}
}
You should try the Moondrop Space Travel, you can buy them for USD 24.99 on Amazon.
- Moondrop is a pretty well known brand in the ChiFi (Chinese Hi-Fi) space.
- They support AAC so they even have good audio quality on Apple/iPhone devices (most cheap earbuds only use cheap Android codecs).
- Normally, their latency is pretty high, but they do have a low-latency mode in case you ever want to play games + take a call.
- It's Bluetooth 5.3 and communicates directly to each earbud (e.g. if you want, you can only use one at a time).
- And, they have active noise cancellation that's surprisingly good (in fact, it's amazing for $25!).
IMO, the main downsides are:
- Their app is meant to be horrible (I didn't even bother to install it). Not a big deal, unless you want to play around with EQ, customizing what the touch controls do, or upgrade the firmware.
- There's no way to control the volume via touch controls (although maybe the app allows you to change this)
- Even though it supports Bluetooth 5.3, I don't think it supports Bluetooth LE Audio and the LC3 codec.
These earbuds are probably completely uneconomical to recycle, but at least at $25, they probably didn't have too much of an environmental impact when they were created (assuming that the cost of the item is roughly correlated with the environmental impact of the item).
One reason might be that `text/*` files follow the POSIX standard for text files [1], where no lines can exceed `{LINE_MAX}` bytes in length (and `LINE_MAX` depends on your OS).
I don't believe the YAML spec has any rules on how long lines can be, so this means that some files won't technically be text files. (and some UNIX tools line-based tools might not work correctly on them).
I've had the same issue with some wired IEMs on iOS, using Apple's official USB-C to 3.5mm adaptor. I even have the EU model A2155 of the USB-C to 3.5mm adaptor that's supposed to have half the power of the US model.
What I found that helped was to create a custom Shortcut that "Set Media volume to 1%". iOS reports that this is 48 dB when playing pink noise. I managed to hit 47 dB when dragging to volume slider on iOS below 1%, but the Shortcuts app only seems to support integer percentages.
In my case, even the 1% volume level was too high in a quiet room, but some apps have a custom EQ setting that you can use to lower the volume further. E.g. if you're using Apple Music, you can go to Settings -> Music -> EQ and pick "Loudness" to lower the volume further.
Unfortunately, they're not great to use with a phone in your pocket, since then the motion of walking around will adjust the knob and change the volume.
Although, come to think of it, I could probably just glue the knob into a fixed −10 dB of attenuation and then use software volume control to change the volume.
I have also noticed that those passive inline volume knobs tend to adjust the right and left channels by different levels, especially with low-impedance outputs like IEMs, but that might because the ones I've bought cost ~US$2 from AliExpress.
I could probably also fix the issue by buying a worse/less-powerful USB-C to 3.5mm DAC. The official Apple one is pretty well liked by the audiophile community, since it's powerful for the price, which is great if you have high-end headphones, but horrible if you have earbuds/IEMs.
Weirdly enough, the same Apple USB-C to 3.5mm DAC is much quieter on Android, since it defaults to a low hardware volume on the DAC, and Android then only uses software volume control to lower the volume, see https://issuetracker.google.com/issues/242221770.
The Pixel 6 and Pixel 7 apparently does have the hardware/software needed for Suica, even on non-Japanese editions of the phone.
However, it's blocked by Google in software depending on the device SKU (maybe because Google doesn't want to pay licensing costs?). If you have a rooted Android phone, you could bypass this check, see https://github.com/kormax/osaifu-keitai-google-pixel.
Hopefully it means that a future version of the Pixel will officially support it world-wide, but who knows. Japan has one of the highest rates of iPhone usage in the world, so there's not much incentive to support Android users.
I'm one of the maintainers of the mermaid-cli project, and unfortunately, no.
Mermaid needs a browser's layout engine to run properly [1], but I haven't yet seen a library that will help us without puppeteer.
And yep, NPM (or another Node.JS package manager) is still needed for installation. I was working on trying to bundle all of mermaid-cli's dependencies (aka Node.JS, puppeteer) into one massive single-file exe last weekend, but it's seems we're blocked by missing features in other packages [2].
If anyone has any ideas on how to implement these things easily, feel free to help-out :) I'm also not a big fan of puppeteer, so I'd love to see a way to go without it.
My guess would be that text layout and measuring is something that's very easy to offload to the browser, yet, if you want to do this without, you're pulling in a whole lot of other dependencies (text rendering is quite complex) that you maybe cannot reasonably call from JS.
That's pretty much it. All modern browsers come with CSS layout functions [1], even Internet Explorer did! Pretty much every other Web API can be implemented in Node.JS using something like JSDom [2], but the CSS layout engine is the main missing feature. And the creator of JSDom estimated it would take 3-6 months of full-time work from a talented engineer to implement something like this [3], so this might take a while.
---
Just to give you an idea of how hard this would be, Mermaid let's people use custom fonts, with fallbacks, so diagrams can look quite different depending on what font people have installed.
The current default font is Tahoma [4], which is owned by Microsoft, so Linux desktops usually render the diagrams slightly differently than on Windows/MacOS desktops.
People can also have different default font size in their browser/OS settings, and that will affect things too.
Finally, you also have things like ClearType [5], where the text is rendered differently depending on the sub-pixel arrangement of your monitor!!
I think we could get a basic version that partially works by implementing only a subset of the layout functions and hard-coding one specific font in, but even that would still be a fair bit of work.
1. SVGs generated by Mermaid use the SVG 2 features, but other than browsers, most libraries only support SVG 1.1 features, i.e. <https://github.com/mermaid-js/mermaid/issues/2102>, which is what the other comment mentioned.
2. Mermaid requires a browser layout engine to render the diagrams (your issue), i.e. <https://github.com/mermaid-js/mermaid/issues/3650>. This is something I also really want to fix (I maintain the [`mermaid-js/mermaid-cli`][1] project and we need to use Puppeteer/Headless Chrome to render mermaid diagrams, which isn't ideal.) However, I don't think this would be easy, since we'd need a browserless tool that supports a browser-like layout engine (although I'm hoping that [Servo][2] might eventually be able to support it).
And if you do want to do headless renders of Mermaid diagrams, I'd recommend using (or adapting, since the code is all MIT licensed and I'm not aware of one that uses Selenium):
- <https://github.com/mermaid-js/mermaid-cli>, which uses Puppeteer as the headless browser API.
- <https://github.com/remcohaszing/mermaid-isomorphic>, which uses Playwright as the headless browser API.
And make sure that whatever server is doing the headless renders of Mermaid diagrams has all the correct fonts installed!
[1]: https://github.com/mermaid-js/mermaid-cli
[2]: https://servo.org/