How to create an Indian-language PDF with DocRaptor fonts
Create a DocRaptor PDF with the right font coverage and script shaping. Configure @font-face, submit HTML, and troubleshoot missing or misplaced glyphs.
To create an Indian-language PDF with DocRaptor, put your Unicode text in HTML, load a font that covers its script with CSS @font-face, apply that family to the text, and submit the HTML as document_content to DocRaptor’s PDF API. Then inspect output containing representative text from the target language. Both the font’s glyph coverage and the renderer’s OpenType shaping support matter.
“Indian-language” can mean text written in distinct scripts, including Devanagari, Bengali, Gurmukhi, Gujarati, Odia (called Oriya in some older technical documentation), Tamil, Telugu, Kannada, and Malayalam. There is no single font setting that covers every language equally well. Prince’s release history lists OpenType shaping support for these scripts, but that historical renderer information does not identify the Prince version assigned to a particular DocRaptor account. Prince release history
1. Choose a font and confirm shaping support
Start with the language and script in the document, then choose a font whose character map covers the actual text. A font can include the individual characters and still need the renderer to shape them into the correct combinations and position marks correctly.
| What to check | Why it matters |
|---|---|
| Script and glyph coverage | The font must contain the characters used in the document, including signs, punctuation, and numerals where needed. |
| OpenType shaping | Indic scripts use substitutions and mark placement; glyph coverage alone does not guarantee correct rendering. |
| Font format | DocRaptor says WOFF2 requires Pipeline 8 or higher. Confirm your account’s pipeline if you plan to use WOFF2. |
| Weights and styles | If the document uses bold or italic, provide those font faces where available and inspect them separately. |
| Font retrieval | A web font URL must be reachable from the rendering environment. |
Prince’s styling documentation names Lohit Devanagari and Noto Serif among Devanagari/Hindi examples. Prince 13’s November 2019 release notes specifically mention Indic2 shaping support for newer fonts such as Noto Serif Devanagari and Nirmala. These are renderer-specific references, not a guarantee about the Prince version in your DocRaptor account. Prince styling documentation · Prince 13 release notes
2. Add the font to your HTML
Use a hosted font file or a font already available to the rendering environment. This example shows a hosted WOFF2 font. Replace its URL, family name, language tag, and sample text with your own values. The URL must be accessible to DocRaptor’s renderer, and WOFF2 specifically requires Pipeline 8 or higher.
<!doctype html>
<html lang="hi">
<head>
<meta charset="utf-8">
<style>
@font-face {
font-family: "IndianText";
src: url("https://your-host.example/fonts/your-script-font.woff2") format("woff2");
font-style: normal;
font-weight: 400;
}
body {
font-family: "IndianText", sans-serif;
}
</style>
</head>
<body>
<p lang="hi">यहाँ अपना परीक्षण पाठ रखें।</p>
</body>
</html>The HTML language attribute should describe the document or section’s language; it does not select or install a font. The CSS family name in font-family must match the font-family descriptor in @font-face. DocRaptor’s custom fonts documentation covers custom web fonts; its tutorial demonstrates the HTML and API workflow.
If your document uses bold and italic, add matching declarations and files instead of assuming the regular face will look right in every style. Prince may synthesize missing bold or italic styling, which can change the appearance. Verify each style the production document uses. Prince font and styling behavior
3. Submit the HTML to DocRaptor
DocRaptor accepts HTML as document_content. The following is a runnable Python example using the documented API pattern. Set your API key in an environment variable and save the HTML as document.html. The example uses test mode, which produces a watermarked test document; remove that setting when you are ready to create a non-test document, following your account’s DocRaptor configuration.
import os
import requests
api_key = os.environ["DOCRAPTOR_API_KEY"]
with open("document.html", "r", encoding="utf-8") as source:
html = source.read()
response = requests.post(
"https://docraptor.com/docs",
auth=(api_key, ""),
data={
"doc": {
"document_content": html,
"document_type": "pdf",
"test": True,
}
},
timeout=120,
)
response.raise_for_status()
with open("document.pdf", "wb") as output:
output.write(response.content)
For exact account-specific request details and current API options, follow DocRaptor’s custom fonts tutorial and API documentation. Keep the API key on the server; do not embed it in public HTML or client-side code.
4. Validate the rendered PDF
Test with representative production text, not just a row of basic letters. Include the combinations, vowel signs, marks, numerals, punctuation, and normal/bold/italic styles that occur in your documents. Inspect the pages visually, and check selectable or searchable text if those properties matter to your workflow. These checks help catch missing glyphs, unexpected fallback, incorrect mark placement, and changed line breaks.
Prince automatically tries other fonts in the family list when glyphs are missing. A PDF showing visible text can therefore still contain fallback glyphs rather than the face you intended. For diagnosis, Prince documents a prince-no-fallback mechanism that makes missing glyphs warn instead of silently switching, where that mechanism is available in the relevant environment. Prince font fallback documentation
5. Common problems and fixes
| Symptom | Likely cause | What to check or change |
|---|---|---|
| Text appears in a different typeface | The font did not load, the family name does not match, or fallback supplied missing glyphs. | Check the font URL, the @font-face family descriptor, the applied CSS rule, and glyph coverage. Use no-fallback diagnostics where available. |
| Empty boxes or missing characters | The chosen font lacks required code points or could not be retrieved. | Confirm the actual Unicode content and script coverage, then verify the resource is reachable to the renderer. |
| Letters appear but combinations or marks look wrong | The renderer may not support the shaping model required by that font, or the font may be unsuitable. | Reduce the document to a small representative sample and check the DocRaptor pipeline/renderer version with DocRaptor. Prince 13’s Indic2 note is version-specific. |
| WOFF2 font is ignored or unavailable | The account may not be on a pipeline that supports it. | DocRaptor specifies Pipeline 8 or higher for WOFF2. Confirm the account pipeline or choose a format supported by that environment. |
| Regular text looks right, bold or italic does not | The corresponding face may not be declared, causing style synthesis or fallback. | Declare the available weight/style files and inspect the styles used in output. |
| Line breaks or page count changed | Font metrics, fallback, or weight differences changed text measurements. | Verify the intended face loaded consistently; then review widths, line heights, and page breaks against the rendered PDF. |
| Legacy text renders as unrelated symbols | The source may use a legacy-font encoding rather than Unicode text. | Confirm the underlying characters are Unicode. The cited DocRaptor and Prince references do not provide a conversion procedure for legacy encodings. |
6. Reliability, speed, and cost considerations
Reliable output depends on making the font resource consistently available to the renderer and using a format supported by the account’s pipeline. A hosted font adds a resource retrieval dependency; an unavailable file can lead to fallback or missing glyphs. Keep a small representative PDF sample in your document-generation checks so font or renderer changes can be spotted before they affect larger documents.
Font-loading and PDF-generation time can depend on document size and external resources. The cited documentation does not provide a rendering benchmark or a cost comparison for Indian-script fonts, so estimate latency and API cost using your own document volume and DocRaptor account terms. Do not infer shaping quality from a fast response or from the fact that a PDF was returned.
7. Frequently asked questions
Can one font cover every Indian language?
Do not assume so. Choose based on the script and characters in your actual content, then inspect that combination in the target rendering environment.
Does setting lang="hi" install Hindi fonts?
No. It labels the content’s language. Supply or select the font separately with CSS or renderer-available fonts.
Does a visible PDF prove the requested font was used?
No. Prince can fall back to another font for missing glyphs, so inspect output and diagnose fallback when needed.
Which Indian scripts should I account for?
Depending on the content, the target may be Devanagari, Bengali, Gurmukhi, Gujarati, Odia, Tamil, Telugu, Kannada, or Malayalam. Specify the actual language and script before choosing a face.
Or skip the browser setup
DocRaptor creates PDFs from HTML. If you also need clean website screenshots to document or review rendered pages, ScreenshotNeo captures a page with one GET request. Its screenshot API is separate from PDF generation, so use it for screenshots rather than as a replacement for the DocRaptor PDF workflow.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpSee the ScreenshotNeo API documentation for request options. Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000.
