Fix Bold Font Spacing When Converting HTML to PDF in Power Apps
Diagnose bold spacing changes in Power Apps PDFs by isolating fonts, HTML controls, conversion routes, and renderer limitations.
Start by identifying the conversion route. If your app uses the native Power Apps PDF() function, compare the HTML or control output on screen with the generated PDF, then test the selected font and its bold face. Microsoft documents that bold and italic styles may not appear in generated PDFs for some fonts, but its documentation does not define one universal CSS fix for bold-spacing defects.
This guide gives you a controlled way to find where the spacing changes, how to test fonts and markup, and when to change the conversion workflow.
What causes bold text spacing to change?
There are three likely stages:
- Source markup: HTML, CSS, or rich-text output already contains unexpected font or spacing rules.
- Power Apps control rendering: the HTML Text or Rich text editor control sanitizes or interprets the markup differently from a full browser.
- PDF rendering: the PDF engine substitutes a font or fails to apply a bold face. Microsoft specifically warns that some fonts may lose bold and italic styles in generated PDFs.
That warning does not prove every spacing problem has the same cause. Treat font, markup, and device changes as controlled tests.
1. Confirm which Power Apps conversion route you use
| Route | Input | What to verify |
|---|---|---|
Native PDF() function |
A screen or supported control | Experimental-feature status, selected font, PDF options, and device context |
| HTML stored in a flow | HTML payload or file | Whether the flow converts HTML to PDF or to plain text; these are different operations |
| Third-party connector | Connector-specific HTML or file input | Current licensing, limits, regions, CSS support, and font behavior |
The native function exports supported screen or control content; it is not documented as a general-purpose arbitrary HTML conversion API. Microsoft’s Content Conversion connector warning about HTML-to-plain-text conversion should not be treated as evidence about PDF rendering.
2. Build a minimal reproducible sample
Remove galleries, images, nested containers, and dynamic formulas. Keep one label or HTML Text control with normal and bold text. Record:
- font family and size
- the exact HTML or control properties
- Power Apps client and device
- the PDF function call and options
- the generated PDF beside an on-screen capture
If the on-screen text is already wrong, fix the source pipeline first. If the screen is correct and only the PDF differs, focus on the PDF renderer and font.
3. Test semantic bold markup and explicit font settings
For an HTML Text control, use a small sample such as:
<div style="font-family: Arial, sans-serif; font-size: 16px; line-height: 1.4;">
Normal text
<strong style="font-weight: 700; letter-spacing: normal;">Bold text</strong>
</div>Set the control’s Font, Size, and padding properties explicitly. Compare <strong> and <b> in separate samples, and test CSS font-weight separately. Change one variable at a time.
Microsoft’s HTML Text control documentation notes that it expects relatively positioned HTML and that some default browser styling may be removed. A layout that looks correct in a browser can therefore differ inside the control.
4. Check the font and its bold face
- Write down the actual font family applied by the control.
- Test a common font with a distinct bold face, then test your production font.
- Compare regular and bold text at the same size and line height.
- Check whether the PDF substitutes a different font or drops the bold weight.
Do not assume that setting font-weight: 700 creates a true bold face. If the selected family has no usable bold face in the PDF environment, glyph widths and spacing can change.
5. Inspect Rich text editor output
If the content comes from the Rich text editor, inspect the HTML it produces before passing it to another control or flow. Microsoft says the editor removes script, style, object, and unsupported HTML elements and attributes. Styles composed upstream may therefore disappear before PDF generation.
Keep the stored HTML simple: semantic bold tags, inline properties that the target control supports, and no dependency on external stylesheets. Save a copy of the editor output for your reproducible sample.
6. Generate the PDF with explicit options
Enable the PDF function in the app’s experimental features if your environment still requires that setting. A basic canvas-app example is:
Set(
varPdf,
PDF(
Screen1,
{
Size: "A4",
Orientation: "Portrait",
Margin: "0.5in",
DPI: 150,
ExpandContainers: true
}
)
)Use the screen or supported control that actually contains the content. Options such as paper size, DPI, margins, orientation, and container expansion affect output dimensions and layout. They are useful for clipping and pagination diagnostics, but Microsoft does not document them as a fix for bold spacing itself.
Generation happens on the device, so device capacity and client context belong in your bug report.
7. Compare each stage
| Observation | Likely area | Next test |
|---|---|---|
| Bold spacing is wrong on screen and in PDF | HTML, editor output, or control properties | Inspect sanitized HTML and simplify CSS |
| Screen is correct; PDF loses weight | Font support or PDF renderer | Test another font and a semantic bold tag |
| Only one device differs | Device/client rendering context | Repeat with the same sample and record device details |
| Spacing changes with nested containers | Layout or container expansion | Test a flat control, then enable container expansion |
Common errors and fixes
| Symptom | Cause to check | Fix or diagnostic |
|---|---|---|
| Bold disappears | Font weight is unsupported for that family in PDF output | Test a different family and compare regular/bold output |
| Bold letters look too far apart | Font substitution, inherited letter spacing, or different line metrics | Set letter-spacing: normal, explicit family and size, then test a minimal sample |
| HTML looks different from the browser | HTML Text control removes or changes browser defaults | Use relatively positioned, simple HTML and inline styles |
| Editor formatting vanishes | Rich text editor sanitization | Inspect its generated HTML and remove unsupported attributes |
| PDF content is clipped | Screen/control scope, margins, DPI, or container height | Confirm the passed control and test margins, DPI, and ExpandContainers |
| Flow output is plain text | HTML-to-text conversion was used | Verify the action and connector; plain-text conversion is not PDF conversion |
| Results vary between runs | Dynamic content, fonts, or device rendering | Freeze content and use a fixed test document before changing CSS |
Performance, reliability, and operational notes
- Keep the sample small: a minimal document makes font regressions easy to compare.
- Control content size: high DPI and large screens increase device work and output size.
- Separate layout from typography: solve clipping and pagination independently from bold rendering.
- Record versions: the PDF function is documented as experimental in the cited Microsoft material, and its status can change.
- Validate every production font: Microsoft’s limitation is font-dependent, so a fix demonstrated with one family is not proof for another.
When to change the workflow
If the native function cannot reproduce the required font fidelity, compare alternatives using these criteria:
- screen/control input versus arbitrary HTML input
- experimental or preview status and support expectations
- font and CSS fidelity on your exact sample
- regional availability, licensing, limits, and page-size behavior
- file storage and flow-integration requirements
The Microsoft catalog lists a third-party Pascalcase HTML-to-PDF connector. Its listing is a workflow lead, not evidence that it fixes bold spacing. Confirm current terms and behavior before adopting it.
Or skip the browser setup
If your actual goal is a clean image of a web page or element rather than a Power Apps screen-to-PDF conversion, ScreenshotNeo provides a single website screenshot API request. See the ScreenshotNeo API documentation for the available options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers report the page verdict and billing result. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The Free plan includes 1,000 screenshots per month without a card; paid plans start at $5 for 3,000 shots.
Create a free ScreenshotNeo account.
FAQ
Is there one CSS declaration that fixes Power Apps bold spacing?
No. Microsoft documents a font-dependent limitation, so test the font, markup, control, and PDF route separately.
Should I use <b> or <strong>?
Test both in your minimal sample. Neither tag is documented as a universal fix; the result depends on the control and font.
Does increasing DPI repair bold text?
DPI changes output resolution. It can help with raster sharpness, but it is not established as a fix for missing or incorrectly spaced bold faces.
Why does browser HTML differ from Power Apps HTML Text?
The control has its own HTML behavior, expects relatively positioned markup, and may remove browser defaults.
Is the native PDF function a general HTML-to-PDF service?
No. It exports supported screen or control content in a canvas app. A connector or external service follows a different workflow.
What should I include in a support ticket?
Provide minimal HTML, font family and weight, editor/control output, PDF function call, app and device details, and side-by-side screen and PDF samples.
Checklist
- Identify the conversion route.
- Compare on-screen control output with the PDF.
- Inspect sanitized Rich text editor HTML.
- Set font family, weight, size, line height, and letter spacing explicitly.
- Test a second font and a minimal sample.
- Verify screen/control scope and PDF options.
- Record device context and reproduce before escalating.
Sources: Power Apps PDF function documentation; HTML Text control documentation; Rich text editor documentation; Content Conversion connector documentation.
