Some normal text for testing linking and tagging styles. links should look identical to #tags. Seb said we should use colour 3 but I don't know if I like it, so checking it out amongst other #text to see if it looks alright when it isn't so isolated...

I wonder if equations like $A = \pi r^2$ render on our site?

Do large equations, like this one work?

$$\frac{\partial x}{\partial y} = \sqrt{\Sigma x^{y^2}} \therefore b = a$$

We're not only re-testing Code Blocks and Code Blocks but also filler word Code Blocks #codeblocks and Code Blocks

Code Blocks with lots of text to see if the 'copy' button sits where it's supposed to. making this line a bit longer to see if it intersects with the copy button too.
'\n' here which is placed exactly where it appears in the mdx file. When we hav|e looooong lines (not THAT long, still
less than 120 chars), we should see a scroll bar appear.

checking $\Mu \alpha \theta$ in code blocks
double newline for this one.
newline
newline
newline
newline
newline
newline
newline

But we're now also testing #callouts.

FBR ROM

A test of the FBR branded callout

normal text again

A plain quote

for plain quotations

An attributed Quote

Person who said the things

The things they said

An unattributed quote

The things that were said don't need to be attributed to someone

This summary is gonna summarise this text so well you're not going to BELIEVE how summarised the below callout is going to be it's kind of unbelievable really... Testing some longer summaries, like MUCH longer summaries with different effects and stylings; a bunch of different #freaky text inputs in callout summaries.

and some more #variety in the callout body.

So we can see what callouts are really capable of
160mmx160mm
what happens if I don't put the `>`
>it breaks
checking $\Mu \alpha \theta$ in code blocks inside callouts

I think some of these will work

#tags and modified or altered text in the summary no longer fail! #tags and code blocks do not render as usual, but I don't think this is something we need to worry about right now.

A new callout has appeared!

It's a wild mDOT!

And finally,

A default callout to show the base styling that the other callouts are built on top of. checking $\Mu \alpha \theta$ in callouts

Text with a marker marker textnote body after the note.

a block-level marker a block-level note.

A longer body of more text to see what the sidenotes really look like in a realistic context with a marker marker text is also longer in this example as well as the note body text, we need to check different use cases and this is more longer text after the note to make the paragraph more complete looking. We also get to see justification at work with sidenotes beside it and it's looking quite good. Some style tweaks will resolve anything that is less than desirable and we'll be golden. And what about a sidenote that has no marker text? This should work as well. If it doesn't we ought to fix that. Yep. It works! It's odd, this paragraph does not look justified in my current view. I don't know if that's because of the sidenotes or if this is how paragpraph breaking is being handled by the justifier. I'm writing more and more and more and here's a linebreak... NOW which shouldn't affect the way the text is rendered. I am not happy about it either way, no matter the root cause. The effect is the same. Text looks inconsistent and inconsistency looks like doggy doodoo. How sad. Another linebreak HERE boom and just like that we're on a new line. Isn't technology amazing?!?! I don't actually think this is THAT exciting. I just needed to put some text here to see what happens.

A little more breathing room here too. Wait but this is the first time. The temporal sequence is lost in the rendering of this text file.

blank

space

words to test the other potential situation in which notes breakLike this and a line after just to be sure

and some more space

for space

to not crowd the sidepane

And I understand that equations like this$5 \times 5 = 25$ I think should work,

some space to breathe, the sidenotes got a little too crazy.

but I'm not too sure about equations like this$$\alpha^2 = \beta$$ this, they might not work.

Let's have a little more room to breathe here

The sidenotes like to get a little close, they don't understand personal space. They are just pixels on a screen after all.

I think references to equations $4 \neq 5$ Obviously like this works too.

a few

more lines

to break

the space up

Notes without the sidenote also work as <Sidenote>note text!</Sidenote> The naming here is a little ambiguous, why is the "sidenote" tag the one associated with body text and the "note" tag the one associated with the sidenote text? Seems backwards.

But what if we have

A tiny bit of code foo

More lines

So the sidenotes can

maintain some separation

so I can actually read them.

or what if we have a lot bit of code?! foo bar That doesn't work so great. Fair enough, we shouldn't ever be doing that anyway to be fair. I was just testing it out.

---

References (siderefs) are a different animal from sidenotes: the in-body marker is a superscript numeral (¹, ², ³, …) that reads like a sidenote's letter but counts, and the IEEE-style [1], [2], … bracket form appears where the entry is listed — the References section below, always, in document order. In the narrow view the reference text on the side drops away and only the superscript numeral stays, because the full reference always appears in the References list below.

Here's a plain one: Vaca Guerra, C., et al. Prediction of espresso flow rate. J. Coffee Sci. 12 (2024): 3–9. — the [1] marker is pure CSS, the author never writes a number.

A reference body can be markdown-rich, like this one with emphasis, a code span, and a link inside. — the entry in the References list below should keep that formatting.

And equations where $k = \beta T$ converges as $T \to 0$. should render exactly like body-text math.

Adjacent markers on one line: Alpha, A. First. 1999.Beta, B. Second. 2000. — both should count consecutively.

A sidenote inside a reference is not parked in its own column: A ref carrying a note withinit stays inline in the entry's text.

---

Footnotes (the Obsidian-style [^id] / [^id]: pair) render as numbered sidenotes: the label is authoring-only, the visible number is the counter letter, the definition's body is hoisted to the note, and there is no footnote list at the bottom of the post.

Numbered reference.A footnote body with emphasis, a code span, and even math $e^{i\pi} + 1 = 0$ inside. A named one.Named labels are never shown — this body belongs to a named reference. The first again.A footnote body with emphasis, a code span, and even math $e^{i\pi} + 1 = 0$ inside. And two undefined refs, both left visible as literal text: [^missing-def] and [^99]

First paragraph of a two-paragraph footnote. Second paragraph (the indented continuation Obsidian uses), flattened into the same note body. is referenced here so the flattening has something to show — its two paragraphs should read as one continuous note.

---

Post Toolkit

Everything an article writer gets to use, one live example per feature — this section doubles as the visual regression test for the content pipeline.

Text and links

Bold, italic, nested italic inside strong, inline code, an internal link to another post, an external link, and an auto-linked hashtag like #coffee — two trailing spaces at line end force a hard break:
this line breaks here

The CTA button styling — internal links route through the window manager, external links open in a new tab:

Structure

Third-level heading

Fourth-level heading

Unordered lists nest to any depth:

• top-level bullet
  • nested bullet
    • third level
• another top-level bullet

Ordered lists nest the same way:

1. first item
   1. child of first
   2. second child
2. second item

---

A horizontal rule divides sections of a post.

Plain blockquotes stay plain — the quote bar, no icon, no background.

Callouts

Callouts are > blockquotes whose first line starts with [!TYPE]: callout has the base styling, fbr and mdot carry their icons (the mDOT one above hosts the live widget), a - after the type starts the callout collapsed, and unregistered types still render — default styling, type name uppercased as the label, no icon — so new callouts work before they are registered:

This type is not in the callout registry yet.

Until it is registered it wears the default styling and this type-name label.

Tables

Pipe tables render with column alignment straight from the header row — left, centre, right — and markdown formatting works inside cells:

A wider table

Wider still — wide enough that a narrow window has to squeeze it. The headers break at the space, at the existing hyphen, and (when one word still has to give) with a visible hyphen — never a bare mid-word cut, never a single letter of its own:

Different text alignments

A table inside a callout wears the same grid, just set against the panel:

Dialing in

Attempt	Ratio	Call
1	1:1	WAY under — go finer
2	1:2	under — go finer
3	1:2.6	a little over — go coarser
4	1:2	already tried this one. definition of stupidity.
5	1:2.4	locked in

Dialing in but FBR callout

Attempt	Ratio	Call
1	1:1	WAY under — go finer
2	1:2	under — go finer
3	1:2.6	a little over — go coarser
4	1:2	already tried this one. definition of stupidity.
5	1:2.4	locked in

Code and math

Fenced code blocks get a hover copy button and scroll horizontally on long lines instead of wrapping:

function settle(ms) {
  return new Promise(resolve => setTimeout(resolve, ms))
}

Inline math sits in the text flow ($x = \frac{b \pm \sqrt{b^2 - 4ac}}{2a}$) while display math gets its own centred line:

$$\int_0^\infty e^{-x}\\,dx = 1$$

Figures

A standalone image — one whose paragraph holds nothing else — becomes a figure, its alt text rendered as the caption beneath it:

Sidenotes, siderefs and footnotes

The rest of this post stress-tests the two side systems: marker variations (rich, bare, code and math inside), standalone notes, adjacent siderefs, a nested note, and the Obsidian-style [^id] pair that renders as a numbered sidenote with no list at the bottom. The in-body sideref marker is the superscript numeral; the bracketed [1] form appears only in the References footer.

Ready-made blocks

Drop-in MDX components a post can embed anywhere in its body: <EmbeddedStore /> (the store), <ContactForm />, <NewsletterForm />, and registered page components such as <MdotPage /> — those also render server-side, so crawlers can read their content. <MDotLandingWidget /> is already living in the mDOT callout above.

Frontmatter

The --- header above each post body — every field this post's own header uses, plus the optional extras:

title: "a test"
description: "for testing"
tags: [test]
pubDate: 2026-08-26T12:17:03.301Z
connections: [index]  # posts this post links to in the graph
hidden: false         # true → excluded from the graph and all listings
desktopWidth: full    # post window opens at full content width
# cta:                # optional CTA in the standard slot under the title
#   text: "Reserve early access"
#   link: "https://…"

Coffee Particle Size Distribution

The particle size distribution (PSD) of coffee grounds produced by a grinder are influenced by several factors. Unsurprisingly, the grinder's construction, the alignment of the burrs, the grind setting, and the roasting grade have an impact on the PSD [[@]] [[@]] [[@]]. Less obviously, bean temperature [[@]] and bean moisture content [[@]] both have an impact on PSD, while the bean origin [[@]] has very little impact on the PSD produced.

When trying to maintain the consistency of espresso coffee, the most important factor is maintaining consistent PSDs [[@]]. Looking at the factors that impact PSD we can then determine why there may be inconsistency in espresso coffee extraction in the span of minutes, hours, and days, when everything is seemingly remaining the same.

Grinder

Using the same grinder will produce a more consistent PSD between grindings than using a different grinder due to differences in their construction and burrs.

Burr Alignment

Burr alignment can change over time, leading to differences in the PSDs produced, however, these changes occur slowly over a long period and adjustment is usually required on the scale of weeks to months [@][@].

Grind Setting

Grind setting will only change when changed by the barista.

Bean Temperature

Bean temperature can shift over the course of the day due to both change in ambient temperature, as well as heating of beans in the hopper of a grinder as it heats up due to heavy use, and then the subsequent cooling in periods of minimal grinding.

Bean Moisture

Bean moisture content can change as a result of storage conditions, primarily temperature and humidity [@].

Mathematical Modelling

Espresso Flow Rate Modelling

Vaca Guerra et al. [[@]] found that a known mean coffee particle size and coffee particle size uniformity can be used to predict the flow rate of coffee extraction. A mathematical model to predict the permeability of a tamped espresso puck was found, which was then used to predict flow rate with good agreement with experimental values.

PSD Modelling

The grinding process is highly variable and attempts to elicit mathematical relations between PSD parameters with grinding grades proved unsuccessful, although there is a general trend for the mean particle size and the distribution width to decrease as grind setting is made finer [[@]].

The PSD parameters we are most concerned about when using physics flow models such as the model presented by [[@]], mean particle size and uniformity, are not the focus of the studies that explore the effect of temperature [[@]] or moisture content [[@]], meaning the environmental conditions cannot be used to predict PSD inputs for flow rate modelling. Furthermore, the mean particle size is discontinuous with temperature [[@]], so a physics model is likely not appropriate for predicting PSD based on temperature. The relation between bean moisture content and the mean particle size was not clear, and the uniformity was not presented [@], so is not known if a mathematical model for PSD predictions based on moisture content is appropriate.

The environmental conditions demonstrably do have an impact on the PSD produced by a grinder, but precisely how it affects the outputs does not have a reliable mathematical model. This opens the possibility for the use of machine learning and statistical methods of modelling the environmental effects on the consistency of espresso coffee extractions.

Moisture Modelling

The bean moisture content as a function of bean type and temperature has been successfully modelled using a Support Vector Machine (SVM) for green and parchment coffee [[@]], which may be applicable to roasted coffee as well.

These Relations Still Matter

While there is not a mathematical/physics model for environmental conditions -> extraction time, these parameters are known to impact PSD, which has been shown to impact flow rate and therefore extraction time. This makes a good argument for the use of (MLC) to maintain a consistent extraction time since a traditional feedback control system would be infeasible without direct PSD measurement (see Why PSD Cannot be Measured).