Fonts | Font Troubleshooting and Compatibility for Text Areas
1) Can the spacing be changed / influenced?
Currently there is no system based tools to influence any spacing within the font type, beyond automated justification spacing to fit a specified width. This includes tracking, kerning and leading of any font on the platform. The 'default' metrics of the fonts are used and represented by the browser.
If the default spacing is causing an issue for a particular font, the best current solution is to use an alternative font on the system OR find a similar Google Font which can be added to the platform free of charge.
Top Tip: If you have font editing software, you can change the default spacing between characters and have that font imported to CPP to offer fixed spacing options.
2) Text displays differently between browsers OR the preview is different to the generated print artwork file?
There are multiple contributing factors that affect how the text displays or is positioned in the Smartlink. It is important to understand that this is not a fault or issue with Custom Gateway software, the issue lies with the font file and how it has been created.
The most common queries are:
- There is a noticeable difference in the text alignment/position between the on-screen preview and the generated print artwork (beyond acceptable tolerance)
- The font is rendering differently / inconsistently between browsers / devices
- The product endlessly loads / does not load when a particular font is used
The primary cause is that Operating Systems and browsers render the fonts in different ways, and therefore this has to be taken into account within the metrics of the font file, if the font is to render consistently across the board.
For products which do not load at all due to the font, the font must be repaired or an alternative version sought and installed.
Critical: Custom Gateway cannot guarantee cross platform compatibility for any imported fonts, as this can be affected by factors beyond the influence of our technology. It is the responsibility of the user to test their products as necessary, and / or accept any potential differences and the implications this may have when using non websafe fonts.
For these reasons we recommend the use of fonts that have been optimised for web use as they generally render more consistently across the board, eg Google Fonts.
Users can manually test font compatibility via the Print Test facility to review the preview in multiple browsers vs the output file as necessary.
Should there be a specific font that you want to use that is causing issues, there are 3 potential solutions that should be considered:
- A) Locate and or Purchase a web optimised version of the font.
- B) Update the TTF files manually using dedicated font creation software to optimise for web use
- C) Use a different font / Find a close matching Font - we recommend Google Fonts or https://typekit.com/.
For more information, see:
3) Missing Characters / characters don't match the preview compared to the generated print file
It is possible that for some fonts, certain characters may appear differently in the browser vs the preview. This is caused by the font file not containing the relevant character information - so the browser utilises a fallback font to render the missing character.
In some cases, the end user may have tried to use special / foreign characters or emoji's. These may appear in the preview, but when the artwork is generated by the platform there is a mismatch. This is not that the special / foreign characters have been rendered incorrectly by the system, it is again caused by the font file which does not contain the relevant characters. So there is nothing to render - see here http://www.martinstoeckli.ch/fontmap/fontmap.html
It should be noted that this is not a fault with Custom Gateway software, the issue lies with the font file specifically.
Here is the technical explanation:
The Unicode standard defines 109,384 possible characters that a user can type into a system (most of them are typed by using non-Qwerty keyboards, modifier keys, copy and pasting or using a tool like the windows character map).
The vast majority of fonts will only support a very small subset of these characters, usually most fonts will only support English letters and maybe a few other special characters. A font that supported every single possible character would probably be 100MBs large and not feasible to use as a web font.
What happens in a web browser when the user types a character that isn't supported by the font is that the browser will typically use a system defined fallback font. The problem this presents is that we have no idea what this fallback font actually is (it will differ depending on what fonts are installed, what platform is being used, etc).
Thus it is not possible to draw the character properly in the final artwork.
The only way to resolve completely would be to use a font type that features the necessary characters within the character map. This may involve utilising a different font, or manually updating the original font using specialist font editing software.
To stop users from adding special characters, you can specify the ASCII Preset Input Rule on each Text Area on your products.
4) Special Characters, Apostrophes and Punctuation
This is really a continuation of Point 3 but is worth highlighting on its own. When creating products and assigning fonts to text areas be aware that modern Virtual device keyboards often include a larger array of characters and punctuation than are accessible using the keys on a standard keyboard (note that there are also subtle differences between a Mac and PC keyboard which can also mean Macs are affected by this same issue). These characters are typically accessed by holding down the key on the virtual keyboard to reveal the additional characters:
What this means in practical terms is that is the end-user in the app enters one of these characters and it is not included in the fonts character map, the character will either display as blank or be substituted by the browser using a fall back font. Either one of these responses is problematic from an order perspective as the order will either a) not generate a character at all or b) generate the character in a fallback font which does not match the design font.
There are two preemptive actions which can be followed to mitigate the chances of this problem occurring and a means to fix problematic orders after the fact (although this should not be relied on as it will not work in all cases).
- Preemptive action #1: Use a font with a complete character set
Sounds obvious because it is.
Make sure that the font you are using is Websafe and has an extended character set which includes all special characters and variations that you wish to be available to the user.
All characters can easily be tested both from a Preview and Output perspective by using the Print Test feature on any product that is using the font in question. It is especially important to check the Output file as this could cause costly errors in production.
- Preemptive action #2: Add input rule validation to your text areas
The second is to add validation to your text areas to include an input rule. There is more information on input rules in this dedicated article:
Input rules allow you to specify which characters the text area will accept from the user eg: Whole numbers only, Letters only, ASCII etc.
All of our standard apps support input rules and we would recommend that if nothing else you set your text areas to only accept ASCII as this will prevent the majority of problems with rogue fonts. If you want to make it water tight then the Input pattern code can be modified to add and remove specific characters.
Corrective action #1: Replace the personalisation text on the order in OMS
If you should receive an order with a missing or substituted character it may be possible to correct the problem in OMS if the product was created using Product state.
Edit the personalisation of the order (pencil icon shown above) and check the User Text and Final Text fields. If the user has used a glyph which is not included in the font's character map, you can edit the text in the Final Text field and replace the character they entered with an alternative.
Eg: Perhaps the customer used a grave accent instead of an apostrophe but the font does not include a grave accent character.
If you delete the grave accent character and input a true apostrophe and save the changes, the system will queue and generate a completely new print job.
Check the new output file and that should correct the problem. If not, try using the live edit feature instead (eye icon in image above) and see whether the character you have substituted is recognised. If it works in the preview and not the output then neither character is included in the font character map but this is extremely unlikely as the apostrophe is such a basic symbold.
5) Ligatures and Swashes have limited support
The Platform has limited support for fonts that feature ligatures and swashes. Such fonts will typically display incorrectly in the preview, often with one or more problems including; incorrect rendering, incorrect spacing, missing characters or browser fallback font substitution.
We advise that any products set up with such fonts are thoroughly tested. Please check all characters both individually and linked , making sure to check the preview and more importantly the system-generated output using the product Print Test., before the product is used to process live orders.
Related Articles
Fonts | What Fonts Are Available?
A list of publicly available Google fonts for use with 2d and 3d Products can be found the Text Area > Formatting rollout within the product edit interface. The system currently houses 363 Google Fonts for Public use. *There is currently a known ...Text Areas | Options > Hyphenation
Level 3: This article will presume product setup knowledge and familiarity with Text Area functionality Overview Hyphenation is an advanced text feature that automatically splits words at a suitable place to allow the content to 'fit' to a specified ...Text Areas | Custom Fonts - How to create your own hand-drawn font types for CPP!
Custom Fonts It is possible to create your own Custom Fonts to be added to your own Font Group on the CPP. These can be hand-drawn or digitally designed - the choice is yours! All we need is the TTF or OTF file. Details 1. You can create your own ...Text Areas | Formatting > Default font and Font Sets
Text Areas | Text Boundary Options
A Text Boundary defines an area WITHIN the Print Area in which the text can appear. It is defined using the X and Y coordinates system in the same way that an Image Area is defined by. For example X and Y denote the top-left corner of the boundary. ...