When an accented name looks correct when typed but becomes a question mark or another symbol after CSV import, stop before personalizing the blank. Compare the spelling at each file boundary: original list, exported CSV, imported text and final artwork. Correcting the wrong stage can leave the real problem in place for the next order.
Typed correctly, imported incorrectly
A January 2026 support case reports a Portuguese character displaying correctly in typed text but not through LightBurn CSV Combine. Support suggested investigating UTF-8 export and requested a sample. That is a useful lead, not proof that encoding explains every missing character.
Use the comparison in software you already use for design preparation. CSV Combine is a LightBurn feature in that case; it is not a promised P2 control or TYVOK software feature. The final file must still travel through the current supported P2 workflow.
Follow one name across four stages
| Stage | Compare | If it differs |
|---|---|---|
| Customer-approved source | Full spelling, accent and capitalization | Resolve the original text before exporting |
| CSV opened with explicit encoding | Actual character, delimiter and field boundary | Re-export a copy with a documented matching encoding |
| Text imported into the design tool | Imported name beside a manually typed reference | Investigate import settings or font coverage separately |
| Final supported artwork | Character shape, spacing and size after reopening | Hold output until the transferred file matches approval |
Keep the original spreadsheet unchanged. Select a small test set containing the affected character and a plain-letter control. For example, invented names such as José and Jose expose whether the accent survives; they are test text, not customer records. Reopen an exported copy with the chosen encoding explicitly selected instead of relying solely on an application's automatic guess.
If typed and imported versions both show an empty box, examine whether the chosen font contains the required glyph. If only the imported text changes, examine encoding and import interpretation first. Some exports may include a byte-order mark, and applications can handle it differently. Follow the software's documentation and verify the resulting characters; there is no universal instruction to add or remove that mark for every workflow.
Do not replace the original text with outlines until spelling is correct. Converting the wrong glyph to a path only preserves the error. Keep an editable version alongside any approved outlined or raster output.
Release the names, then release the layout
After character integrity is established, use the variable-name card proof to check row assignment and missing names. Those checks prevent a different mistake: a perfectly spelled name on the wrong card. If the correct glyph generates an extra path during fill preparation, inspect the fill-preview artifact independently.
The P2 configuration does not determine a customer's spelling or a CSV's encoding. Complete this screen-based proof before any material test, then check the final mark dimensions against the selected setup.
Is a question mark always an encoding problem?
No. The original data may already be damaged, the importer may interpret it differently, or the font may lack the glyph. Comparing the four stages identifies where the first change occurs.
Can I remove accents to get the job finished?
Not without the customer's explicit approval. An accent can be part of the person's name. Preserve the approved spelling and resolve the transfer problem before producing the item.
