# A prompt for creating your own corporate typeface

Help me create an original typeface family for my company. I need an individual style for presentations, code, the website and other materials. The goal – harmonious, professional text with recognisable features that match the spirit of the company. I need working fonts, sources and a clear way to continue developing them.

I am not a type designer. Explain decisions in plain language and run the work in stages, so that we do not spend time refining options I will not choose.

1. First clarify the company's line of business, the character of the brand, the languages needed, the places of use and examples of typefaces I like. Separately find out whether a typeface for programming is needed. Propose the minimal contents of the first release and the acceptance criteria. Agree them with me before development.

2. Prepare three small concepts on the same words and paragraphs. Show the differences in character, width and rhythm of the text. Use the references as a guide for the impression. Do not extract and do not copy other people's outlines. If you propose a base taken from an existing open font, explain its origin, licence terms and limits on originality in advance. Fully develop only the concept I choose.

3. Start with the regular style and achieve harmony of words and paragraphs. Check the letter height, the stroke thickness, the spacing and the kerning, that is, the adjustments of distances between particular pairs of letters. Then develop the agreed weights and the italic. For the monospaced family, check the equal width of characters and the distinguishability of similar characters in code. Do not substitute artificial thickening or slanting in the browser for finished styles.

4. Create a permanent A4 proof sheet and its web version. Include my real texts, headings, paragraphs, a table with numbers, currencies, punctuation and code, if it is needed. Add diagnostic lines for similar characters. Compare versions at the same size, line width and line spacing, without compensating for the typeface's shortcomings with different settings. Check all the agreed languages and styles, small text and light and dark backgrounds.

5. Work in short iterations. Show the problem, make a targeted fix, rebuild the fonts and compare the result with the previous version on the same sheet. Keep the versions and the reasons for the changes. If it gets worse, roll the fix back. After changes to shared sources, check the affected styles, so that fixing one letter does not make the neighbouring ones worse.

6. Run FontBakery with the applicable universal, googlefonts and adobefonts checks, OTS on all files of the release package and an available Font Validator as an additional check. Check the names, metrics, language coverage, outlines and the working of the declared features. Look at the result in FontGoggles, Wakamai Fondue or FontDrop and in the real browsers and programs where I will use the typeface. For a variable font, check the intermediate axis values, not only the extreme ones.

7. Keep the original reports. Separate font errors, tool limitations and catalogue requirements that do not apply to private corporate use. Do not hide FAIL and do not change thresholds for the sake of a green report. Fix real errors; explain disputable exceptions and agree them with me. Mark a check that was not run as not run. Do not promise inclusion in Google Fonts on the result of one profile.

8. Before release, ask two independent agents to check the design and the technical results separately against the same criteria. Give them the files, the proof sheets and the reports. Have each one rank the findings by importance. Fix the well-founded findings, repeat the affected checks and send the updated version for a repeat review. Do not call an automatic PASS proof of artistic quality.

9. Assemble the final archive with the agreed font formats, the sources, the build method, the licence, an example of connecting the fonts to a website and installation instructions. Attach the proof sheets, the reports, the list of accepted exceptions and the checksums of the final files specifically. Report what has been checked, what remains unchecked and for which uses the release is accepted. Do not publish the materials and do not change the licence without my decision.

The matrix of mandatory checks must include the following groups. We fix applicability and thresholds before development; we do not treat specific numbers from another project as an industry standard.

| Group | What to check |
|---|---|
| Origin and licence | The origin of the outlines, sources and characters; whether use and publication are permitted. The licence text in the release package and inside the files is consistent; third-party components keep their own terms. |
| Contents and names | All the agreed languages, characters and styles; family names, versions, no installation conflicts. Correct selection of the regular, bold and italic style in programs. |
| File structure | All delivered TTF, OTF and web files open and pass OTS. The tables and checksums are checked. Conversion to a web format and back does not lose characters or features. |
| Outlines | No accidental self-intersections, spikes, degenerate segments or damaged composite glyphs. Inner counters are preserved in the bold styles. Dimensions are measured on the real curves, not on the outermost control points. Intentional overlaps are assessed with the construction and the format taken into account. |
| Metrics and spacing | The baseline and the visible height are consistent; round letters get optical compensation. Accents, ascenders and descenders are not clipped. Spacing and kerning are checked on words, paragraphs and difficult pairs of every agreed language. |
| Text shaping | Check real engines, for example HarfBuzz. Compare precomposed letters and letters with separate accents, including NFC/NFD. Check the positioning of multiple diacritical marks. Do not declare the presence of characters to be full language support. |
| OpenType | Ligatures, alternates, tabular figures and other declared features work when switched on and off. Substitutions do not change the meaning and do not break searching, selecting and copying text. |
| Monospaced text and code | Equal width of ordinary characters and correct zero width of combining marks; columns line up. I/l/1, O/0, Cyrillic Ze/3, S/5, brackets, quotation marks, the comma and the semicolon are distinguishable. Code is checked with ligatures and without them. |
| Variable fonts | The masters are compatible; the axes and named instances are correct. Check extreme, standard and intermediate values, including fractional ones. No jumps in shape, thickness, width or accent position. Record the grid that was checked; do not call the integer weights all the possible values. |
| Screen and print | Real Chrome, Firefox, Safari and Edge on the available systems, standard and high screen density. Small text, headings, all the agreed weights and the italic, light and dark backgrounds. A corporate document is opened in the editor in use; the PDF is checked for embedding, text appearance and clipping. |
| Design | On identical pages, check the rhythm of the line, the colour of the paragraph, the balance of Cyrillic and Latin. Brand features do not make reading worse. An automatic PASS does not replace an assessment of harmony and does not prove the worldwide uniqueness of the design. |
| Release package | The release is built from the saved sources in a clean folder and compared with the approved files. The declared size of the web files, installation and connection are checked. The final archive, reports and checksums refer to the same files. |

For each result, state the file, the tool and its version, the conditions, the status and the evidence. Distinguish PASS, FAIL, WARN, ERROR, SKIP and checks that were not run. Explain the skips. Confirm checks in FontGoggles, Wakamai Fondue and FontDrop with saved results, and when a tool is unavailable, report it. Do not replace checks in real browsers with a single server-side render.

After a substantial edit, repeat the affected checks; before release, run the whole agreed set on the final files. Do not limit yourself to Regular alone. Ask two independent agents to assess the design and the technical quality separately, without telling them your conclusion in advance. If the reviews disagree, reproduce the specific problem and explain the decision. Keep the agreed exceptions next to the original negative results.

Start by clarifying the task and with a minimal plan. I need a good result in a reasonable time, so first we solve the problems that affect the reading of text and the reliability of the files.