That question mark wasn’t in the mockup.

The file opens, screens appear, and the arrows seem to be in place. Then you notice little dashed boxes containing question marks. They are not a creative decision made by your boss. They are the editor saying, “I found an icon, but I do not know how to draw it yet.” A reasonable statement expressed through a graphic that looks vaguely like a much more serious problem.

This happened during a real Telario trial. The initial renderer drew a limited collection of shapes: databases, gears, envelopes, and a few others. Unrecognised icons became placeholders. The document could contain the correct identifier while the renderer had no representation for that name. Archive reading had succeeded; graphical coverage was incomplete. Those are different outcomes, even though users encounter both on the same canvas.

The answer was not simply drawing the two missing shapes visible in a screenshot. First, we needed to identify the collection behind the document, find its original source, and establish the conditions for distributing it in a public repository. The result was a local Font Awesome Free integration with historical aliases, licensing, and checks. The route matters more than the final count: it reveals the work hidden behind an apparently obvious little icon.

1. What a placeholder actually means

A placeholder is an interpreter response, not a universal diagnosis of the file. It can indicate a control that was read but is not rendered, a resource outside the supported scope, or a name that has no catalog match. Distinguish those cases before talking about missing data. Appearance alone cannot establish whether information has been lost.

For icons, Telario reads an identifier from control properties and passes it to the renderer. If the name has no recognised graphical representation, the dashed box and ? appear. The original identifier may remain intact in the data. Information can therefore be preserved correctly and still be displayed poorly or not displayed yet. This boundary prevents an incomplete visual vocabulary from being mistaken for a damaged archive.

Start by comparing icons that work with those that do not. If a database appears while a desktop becomes a question mark, incomplete catalog coverage is a more concrete hypothesis than a generic opening failure. Inspect the identifier next. The diagnostic path is small: symptom, input data, resolution rule, and graphical result. It points to the appropriate layer instead of encouraging document edits in the hope that the placeholder will stop complaining. A useful fix begins by explaining the symptom rather than merely hiding it.

2. An icon name is structured data

A name such as desktop-solid is more than an English description. It includes at least a subject and a style. folder-regular and folder-solid can represent the same category through different paths. That distinction affects rendering and lookup. Searching only for a word somewhere in the string may work in a demo and become ambiguous as the vocabulary grows.

The first implementation recognised a few direct conditions. That displayed common symbols but did not constitute a catalog. A broader integration must distinguish an exact name, an alias, and an unavailable style request. Rule order matters: a valid modern identifier should not first be transformed by a compatibility rule intended for a historical name. A plausible icon is not necessarily the correct icon.

The trial document contained desktops, folders, databases, checks, and circle variants. These identifiers helped define realistic compatibility cases without including the private project in the repository. Tests can use the names and synthetic data. Checking desktop-solid does not require distributing the business diagram that revealed the gap. A good example retains necessary technical structure and removes irrelevant organisational context. That makes the issue easier to reproduce while avoiding the false choice between investigating a problem and publishing a document that should remain private.

3. Prefer the original source to extraction

Balsamiq documentation identifies Font Awesome as the source of its icons. That is a better starting point than extracting everything from an installed application. When a collection has a separate official source, investigate it first. Provenance, versions, formats, and usage conditions become easier to establish than when assets are gathered from another product’s installation directory.

This does not establish that every icon in every Balsamiq version is available in one open package. Catalogs, styles, and names can change, and users can import custom resources. The accurate conclusion is narrower: an official Font Awesome Free collection exists under its own licence, and Telario can integrate that material without taking proprietary assets from the original application.

A public repository should explain where distributed assets came from. “It was in the application folder” identifies a technical location but does not clarify redistribution rights. “It was extracted from the official Free release, with the version and licence retained” provides an inspectable chain. That does not answer every imaginable future question, but it avoids building on an invisible assumption. Identify usable material first, then implement the resolver connecting it to document names. The resulting separation between acquisition and interpretation also makes later catalog updates easier to review.

4. Open does not mean without copyright

Icons can be protected by copyright and distributed under a licence permitting use and redistribution. There is no contradiction. The licence establishes conditions; openness does not erase authorship. Ask which material is being used, under which licence, and which distribution obligations apply. “Are the icons copyrighted?” is only the beginning of that investigation.

Font Awesome Free distinguishes its materials. SVG and JS icons use CC BY 4.0, fonts use SIL OFL 1.1, and non-font, non-icon code uses MIT according to the official release licence. Telario uses Free icon paths and includes the upstream licence and attribution. File format matters: a licence read for a font should not automatically be applied to an SVG file without checking the actual terms.

This article describes the material included in the project and the decision made for it. It is not a universal legal guarantee for every future resource. A new source or catalog requires checking the concrete component again. A repeatable process is valuable precisely because it does not depend on the vague belief that “icons on the Internet are free.” Open assets make accurate provenance and permitted uses easier to document. Respecting their terms is part of using them responsibly, rather than an optional administrative step added after the integration already ships.

5. Free and Pro are different collections

A familiar product name does not imply a single licence covering everything it offers. Font Awesome provides Free and Pro material. Telario’s integration selects only styles listed as Free in the chosen release metadata. It does not include the Pro catalog or treat availability inside another product as permission to redistribute that product’s resources.

The visible consequence is that an icon may exist in the Free package in one style but not another. If a document requests database-regular, Telario uses the available Free database-solid variant. The subject remains recognisable, but the appearance is not identical. This substitution is documented and affects visualisation rather than the identifier stored in the document. Preserving that identifier matters for future compatibility work.

This is an explicit compromise. A different style of the same subject may be enough to read a diagram, but unsuitable for a rigorous iconography review. The software cannot automatically know the fidelity required by your task. It should provide coherent output and enough information to assess it. The important promise is the accurate one: a complete included Free catalog does not necessarily cover every variant used in every document created elsewhere. A practical fallback improves usefulness without turning approximate resemblance into a claim of exact equivalence.

6. Pinning a release makes the catalog reproducible

Telario includes 2,060 variants from Font Awesome Free 6.7.2. The count describes distributed variants, not universal Balsamiq archive coverage. The release is named because an unversioned source can change over time, making results harder to reproduce and historical behaviour harder to explain. A catalog is part of rendering behaviour, not merely a decorative dependency.

A script reads official metadata, extracts styles declared Free, retains dimensions and paths, obtains aliases and historical shims, and copies the licence. The output travels with the app. Regeneration can return to the same source rather than depending on files manually collected at different times. That provides a clear basis for both technical review and asset provenance.

Reproducibility also supports testing. Changes in paths, aliases, or style availability can be compared with the earlier release. Updating the catalog means more than editing a version number in documentation: it can alter what users see and the build size. It deserves deliberate checks on names and geometry rather than an automatic request for whatever happens to be latest whenever the editor opens. A stable input makes a rendering difference easier to investigate. Without that stability, a bug report can become a moving target before anyone has reproduced the original result.

7. Historical names need a map

Archives often outlive the conventions used to create them. A historical name may refer to an icon with a different current identifier. Compatibility rules connect those vocabularies without changing the original document. This resembles translation: the same concept needs a representation in the current catalog, while the original expression remains available as evidence.

Telario uses metadata aliases and historical mappings. A name such as file-o requires attention to outline style as well as the word file. Resolution first checks for an exact modern identifier, then interprets suffixes and compatibility mappings. Exact matching has priority so a historical rule cannot rewrite a current identifier that was already valid.

That order mattered during testing. A collision between a modern name and an old mapping can produce a recognisable but incorrect icon. Checking only whether some path exists would miss it. Comparing every bundled variant with its own geometry prevents an overenthusiastic resolver from changing the meaning of valid names. Compatibility should expand what can be read without breaking what was already expressed correctly. The principle applies beyond icons: tolerance at the input boundary is useful only when it does not quietly override a precise, supported representation that needed no interpretation in the first place.

8. Paths travel with the application

Icons are drawn as SVG paths. The renderer does not need a CDN request for each control or a remotely loaded icon font to substitute a character. That fits the editor’s local architecture: once application assets have loaded, the supported collection is available for rendering. Document content does not need to be sent elsewhere to ask what an icon looks like.

Bundling the collection increases distributed content. Complete catalogs do not have zero size. The benefit is independence during use and the ability to embed vector paths in exports. Size should be measured and organised, for example through a dedicated catalog chunk, without pretending that splitting files removes bytes that still need transferring. The trade-off should be described rather than hidden behind a claim of effortless completeness.

Each SVG icon also has its own coordinate system and dimensions. Using the correct viewBox avoids distorting a wide symbol as though it were square. Colour can be applied to the path within the control context. These small details explain why integration means more than copying JSON. Catalog data must be placed correctly within page rendering and checked when it leaves the interface as an export. The chain includes lookup, geometry, composition, and output; success at one step cannot automatically certify all the others.

9. Six cases to check before saying “fixed”

An exact modern name

Begin with a catalog identifier such as desktop-solid. Resolution should return that variant’s dimensions and paths without an unexpected translation. The stronger test compares against included data instead of merely checking whether an object exists. Otherwise, two different icons could both count as success simply because both produce a visible shape.

Extend this check across the entire catalog. Precedence errors can affect names absent from the demo, so the original document should not define the whole test boundary. A good correction adds general capability and checks the mechanism beyond the first screenshot. Ask whether exact identifiers still select their own geometry, as well as whether the missing desktop now appears. Those checks complement each other. One verifies the immediate user problem; the other protects the catalog’s internal meaning. Together they make the improvement reviewable without requiring a human to inspect thousands of icons by eye or assume that a larger collection is automatically a more reliable one.

A historical outline name

Try a name such as file-o. It requires a mapping to a current subject and a style consistent with its historical intention where available. Ignoring style can select the right subject while producing a different silhouette. The result looks plausible but drops part of the visual meaning encoded by the older convention.

Compare output with the corresponding current variant and check supported prefixes. Do not generalise to every string with a similar ending without consulting the catalog. Structured upstream mappings are more useful than a growing series of intuitive replacements. An explicit alias is inspectable; a broad condition can repair one example while changing others. Tests expose that boundary before a real document encounters it. Historical compatibility should retain meaning rather than reward the resolver for returning anything at all. If an old name contains both subject and style information, a useful translation accounts for both or clearly documents the approximation introduced.

A style unavailable in Free

Use database-regular. The expected behaviour is a visual substitution with the available database-solid path. Check both that the icon appears and that the original request is not rewritten in the document model. Displaying an equivalent and changing persisted input are different operations, with different consequences for later use.

Keeping the identifier allows future renderer improvements without first undoing changes made only for display. If a later version provides a better representation, it can start from the original request. Users should know about substitution when style fidelity matters. Recognising the database may be enough for a technical map; a design decision requires the appropriate reference. A fallback is a useful capability, not a certificate of graphical equivalence. Describing it accurately prevents expectations the code cannot support. It also makes a bug report clearer: “the regular style is substituted” is a different issue from “the database icon is missing,” and the next action depends on which statement is true.

A document-specific suffix convention

The observed file included circle-small-solid. Resolution maps it to the solid circle rather than treating small as a different subject. Keep this compatibility rule narrow and understandable. Observing one convention does not justify deleting arbitrary words from every identifier in the hope of finding a familiar shape.

Give the known case a dedicated test and compare it with the base variant. When similar names appear later, inspect their use and meaning first. Control dimensions, requested icon size, and subject name can coexist in properties without being interchangeable. An aggressive resolver may turn an unknown identifier into a valid-looking but semantically incorrect icon. Sometimes an explicit placeholder is preferable to an incorrect symbol nobody thinks to question. Tolerance should remain subordinate to clarity. This principle protects diagrams in which symbols carry operational meaning: a neat-looking approximation can be more misleading than a visible request for investigation, particularly when readers assume every displayed symbol was resolved with exact knowledge of the source.

A genuinely unknown identity

A name outside the catalog should still produce a recognisable unresolved result. The objective is not to eliminate question marks by choosing arbitrary symbols. Without a reliable correspondence, a placeholder communicates a real limitation and invites checking. Hiding uncertainty would make the interface tidier and the diagram less trustworthy.

Try a synthetic nonexistent name and verify that a substring does not accidentally select a shape. The previous renderer may retain specific representations, but a completely unknown string should remain distinguishable. Preserve that property after expanding the catalog. A partial interpreter works better when it recognises what it does not understand. The question mark is not an aesthetic failure to erase at any cost. It is state information, reduced through correct coverage and retained when the alternative is invention. Reliable software should not be judged solely by whether the screen contains warnings. The relevant question is whether its visible certainty matches what the implementation actually knows.

The icon inside an export

The check does not finish on the canvas. Export a supported control and inspect vector paths, dimensions, and the absence of a required external service reference. An icon visible in the interface could otherwise depend on resources that fail to accompany the output. Rendering and exporting need a shared understanding of the asset.

Open the PNG too if that is the actual handoff format. A correct SVG structure matters, but rasterisation is another step. Describe where a discrepancy appears: canvas, exported SVG, or PNG. That narrows investigation and prevents a lookup fix being attempted when the problem concerns scale or output composition. Catalog, renderer, and exporter form a chain. Each link needs a different criterion, and none can be replaced by the satisfaction of seeing the first question mark disappear. A result becomes useful when it survives the route to the recipient, not merely when it looks correct in the development session where the integration was first demonstrated.

10. Brand marks require separate attention

Icon collections also contain company and product logos. A licence for graphical assets does not eliminate rights associated with the represented trademarks. Font Awesome’s official licence notes that brand icons represent their respective owners and do not imply endorsement or affiliation. A public project should preserve that distinction in its presentation as well as its asset notices.

Showing a service named in a diagram differs from adopting its logo as your own product identity. Telario has a separate mark: a window and grid in petrol blue and orange. It does not use Balsamiq branding to imply an official version or partnership. References to the format and original product explain compatibility, accompanied by a visible statement of independence.

These considerations do not need to become a catalog of hypothetical fears. They help describe what is actually distributed and which relationship actually exists. Asset provenance, author attribution, trademark rights, and project identity are related but distinct subjects. Separating them supports concrete decisions when adding a resource, instead of relying on one vague sentence claiming that all icons are free to use. Clear identity also makes the personal story stronger: this is an independent solution to a specific workflow gap, not a borrowed product identity used to lend the project an authority it does not possess.

11. Attribution must travel with the package

A note in a conversation does not accompany a build. The official licence is therefore included among public project files and third-party notices. Someone downloading or serving the application should be able to find component provenance without knowing the integration’s history. Attribution is distributed content, not merely a decision made once during development.

The notice-generation script must preserve the icon licence too. Otherwise an ordinary update could regenerate notices and remove a manually added section. Complete maintenance corrects both today’s result and the process that recreates it. A correct file is less useful if the documented command makes it incomplete tomorrow. This is a small example of why support tooling matters even in a personal project.

Icon documentation specifies release, coverage, substitutions, and regeneration steps. A future change can therefore start from concrete information. Catalog updates and fallback changes have a baseline for comparison. Clarity also prevents the project from being described as having one already-chosen overall licence: the application’s licensing decision remains separate, while dependencies keep their existing terms. Public source visibility, dependency licensing, and permission to redistribute the application should not be collapsed into one assumption simply because all three topics appear near each other in a repository.

12. Coverage and fidelity are different measures

A high count is easy to communicate. It does not answer whether a document’s requested icon is rendered with the correct subject and style. A catalog can contain thousands of variants and still lack a custom identifier. It can resolve a name through a recognisable fallback without reproducing the original appearance. Coverage and fidelity need separate descriptions if users are to assess suitability for their tasks.

The local check on the document revealing this issue traversed four pages and seventy-two icons, with no question-mark placeholders and no JavaScript errors. That is a concrete result for that sample, not certification of every existing archive. Automated tests broaden confidence in the mechanism by checking included variants and alias cases. The two forms of evidence answer different questions and complement each other.

For your own project, first check whether important symbols are recognisable. Then inspect styles affecting meaning or graphical review. When reporting a difference, identify the requested name and observed result. A precise report can lead to another alias, a precedence correction, or a documented limitation. The useful question is not simply “do you have all the icons?”. It is “what happens to this identifier, and why?”. That narrower question can lead to an answer grounded in catalog data rather than an untestable promise of universal coverage.

13. Sustainable maintenance starts with small cases

Regressions can hide in apparently additive changes. A larger catalog changes lookup paths and may alter icons that already worked. Tests should therefore cover more than the originally missing symbols: catalog geometry, style differences, historical names, and unknown identities all matter. Adding capability should not silently weaken established behaviour elsewhere.

For a new issue, build a synthetic fixture with only the necessary elements: Icon type, identifier, colour, and dimensions. Add a group or transformation only when it affects the result. Let the example grow to answer a question rather than because the source archive contained more data. Reduction makes tests readable and keeps private content outside the repository.

The best correction is one another person can verify through a few lines and a nonconfidential example. That matters in a small personal project: future maintenance should not require remembering which customer, page, and message originally motivated every rule. The code can preserve the technical case while business history remains outside the repository. Compatibility grows without the same increase in context debt. A fixture becomes a durable explanation of a requirement, whereas a memory of a screenshot becomes less reliable every time the person maintaining the project returns to it after a few months away.

14. Check the next mockup deliberately

Begin with compatibility information and learn the interface using the demo. When opening an archive, inspect symbols important to the diagram and compare at least one page with a known reference. Do not automatically interpret a different symbol as an error in the document: it could reflect a style fallback or renderer difference. Identify the layer before attempting a correction.

Technical details and provenance are in the icon documentation. Material conditions are in the official Font Awesome Free licence. Balsamiq’s icon documentation explains the source collection without making Telario an affiliated product.

The links serve different purposes: one describes this integration, one supplies licence terms, and one describes the original editor’s use of icons. Keeping those roles separate makes the evidence easier to assess. None should be used as a shortcut to claim that every custom resource or every Pro style is covered by the Free package. Accurate references support a precise statement; they do not expand it beyond what the source actually establishes.

15. A process for the next missing correspondence

Preserve the exact unknown identifier before changing the source icon. Replacing it immediately may fix one image while hiding the case that could improve the interpreter. Record identifier, control type, and observed difference. Separate this technical information from private business context before preparing a public example. Most lookup issues do not need a whole project attached.

Next, inspect the pinned catalog. Is there an exact name, a historical alias, or an unavailable Free style? Each answer suggests a different action. A current name missing from resolution points to code or distributed-data problems. An alias needs a mapping. An absent style needs a documented fallback or declared limit. These are not interchangeable versions of the same defect.

Before introducing a broad rule, test the name in isolation and check neighbouring names the rule could affect. Substring matching is tempting because it produces fast results. It can also create silent errors: a symbol appears, so nobody suspects it is wrong. The placeholder at least requested attention. A plausible image can receive trust it has not earned. Ask whether the rule describes an observed fact or merely an intuitive resemblance, then preserve evidence for the chosen interpretation.

Finally, verify export and retain the case in tests. The fix should survive catalog regeneration and the next renderer change. Update user-facing documentation when visible scope changes, particularly for style substitution. Integration should grow through concrete evidence and remain understandable to someone who never read the original conversation.

That little question mark was a useful reminder. Software can feel nearly complete until it encounters the name it does not know. Solving the problem properly means finding the source, respecting its conditions, interpreting names, and checking the result. Then the desktop finally becomes a desktop again. A modest achievement, but considerably easier to place in a diagram than an unanswered question.