07-18-2018 09:22 AM
Our customer is publishing a map using font Sego UI Semlilight and WebMap 16.5. The font is rendered correctly with png output format, but with svg the font is different. What are the Windows fonts that we can configure for Publishing ??, anyone know how can be suported the fornt Sego UI Semlilight???
07-19-2018 04:42 AM - edited 07-19-2018 04:54 AM
Hi Josep,
I am not seeing such issue on my test VM. Is the font-family referenced in SVG? Is it available on the client computer?
My generated SVG has structure such as:
<style type="text/css" id="gwmstyles"><![CDATA[ ... .r9ruBBe { fill:#000000; stroke:none; font-size:27px; font-family:"Segoe UI Light"; font-weight:400;filter:url(#Halor9ruBBe); pointer-events:visible} .r9ruBBe-H- { fill:#00ffff; stroke:none; opacity:0.501961; font-size:27px; font-family:"Segoe UI Light"; font-weight:400;filter:url(#Halor9ruBBe); pointer-events:none;} .... ]]></style> ... <text x="2609.13" y="664.69" id="r9ruBBeL.0" class="r9ruBBe">Rhode Island</text>
It is the same for Text Feature Classes as well as dynamic labels published to a WMS.
Jan
07-19-2018 01:24 PM
We have a customer reporting that they use their own fonts to represent utilities and representation in SVG has changed going from version 2013 to 2018.
... they are installed and can be seen in charmap, SOME of the fonts or characters within a font do not display the utility fonts, but appear to use a more standard font like Courier or Arial, and the font used for a particular bit of text depends on the map type – JPEG or SVGZ. The cause of this problem is unknown ...
Customer then provides a screenshot of WebMap 2013 SVG where layout is as expected and WebMap 2018 SVG where fonts don't show as expected.
Yet to get to stage of logging Ticket.
07-22-2018 10:35 PM
I apreciate now that Sego UI Semlilight is not shown on the list of standard windows fonts, so I have request to customer to provide details on how to install it on our system to reproduce.
07-23-2018 12:56 AM - edited 07-23-2018 12:57 AM
I think this has something to do with the way the font rendered changed since 2016. Direct2D/DirectWrite rendered was introduced at that time but it appeared to have problems with some fonts. You can try following:
This will force WebMap to use the older rendering engine, however the font render might look ugly.
There also exists a trouble report against Arial Bold, not properly rendered by WebMap.
07-24-2018 08:56 PM
Hi team,
When a layer is in svg mode, its rendering depends on the browser. My testing shows that Chrome seems to have issue with displaying custom fonts even though, the fonts are installed on the machine. The work around I use is to reference a css file that lists all the font.
With this, most browsers (Chrome, IE, Firefox) should show consistently cusom fonts in SVG mode
However, we still observe the problem of displaying custom fonts in PNG mode, we already logged a ticket and currently investigate to find a work-around
Kind regards,
08-07-2018 01:48 PM
We did more analysis on clients fonts that were failing to show in either SVG or PNG.
Bobs workaround worked a treat for SVG. At some stage I must see if that can be extended to cater for custom fonts that are not installed on the client via web font deployment. https://developer.mozilla.org/en-US/docs/Learn/CSS/Styling_text/Web_fonts
Looking at the PNG issue, analysing the customers fonts I found they did not meet the font ttf naming rules.
Most software is forgiving when fonts don't meet the naming rules, but occassionally some software simply won't render them. In this case it turned out to be Chrome SVG rendering and GeoMedia WebMap PNG/JPG rendering.
Please note in following discussion I am not a font expert, but seemed to work for me.
Looking at the font in a suitable editor (I used Type Light which is free, others should work) I noted that the 'Family name' for the font was incorrect.
In this case the family name should not have the word italic at the end - should simply be Orion ISO
So renamed the family name ...
In this case the sub family and full name were correct so left them unchanged.
(Type Light also has a 'Rename font' tool that I suspect might fix up more convoluted cases).
The font file ttf actual file name was not changed - just the internal family name.
Removed the font from the server (had to reboot to 'release' the font) and installed the replacement font on the server only.
Then in GeoMedia updated the defintion used for the text features from the incorrect font family
to the core font family name
Sync'd the legend.
The WebMap PNG content then showed the font correctly. In combination with Bobs workaround it should then work with PNG and SVG.i.e. update font on server only and add .css font mapping file.
Naturally can go the next step and deploy the updated fonts to clients as well which should mean the workaround for SVG is not longer required.
09-02-2018 06:12 PM
After getting the fonts working with PNG/JPG and SVG by adjusting the naming, then found another issue with mult-line text not displaying correctly in PNG/JPG output for specific font. Spacing between the lines was incorrect.
To workaround decided to adopt SVG for the interim. For that to work had to make sure the custom fonts would be available on all modern devices / browsers. Eg android, ios, windows etc.(previously used PNG to ensure lowest common denominator for content involving custom fonts for all devices).
Following worked for us (final decision on adopting as interium solution still pending following further testing, but looking positive):
@font-face {
font-family: 'Orion ISO';
src: local('Orion ISO'),
local('OrionISO'),
url('OrionISO.woff2') format('woff2'),
url('OrionISO.woff') format('woff'),
url('OrionISO.otf') format('opentype');
}
@font-face {
font-family: 'Orion ISO B C';
src: local('Orion ISO B C'),
local('Orion ISO Bold Caps'),
local('OrionISOboldCAPS'),
url('OrionISOboldCAPS.woff2') format('woff2'),
url('OrionISOboldCAPS.woff') format('woff'),
url('OrionISOboldCAPS.otf') format('opentype');
}
local means use the font if it is already installed on the client. Otherwise browser checks the listed formats from the alternative options in waterfall fashion and if browser handles the format download and use it. That means clients that don’t have the font installed still work.
Above setup supports all clients that already have font installed, then for those that don’t have the font installed ie 9+ (7-8 requires adding .eot or have font preinstalled), chrome 3.5+,safari3+ (for older/legacy iOS need to add svg fonts.), firefox 3.5+, opera 10.1+, android 2.2+, iOS 4.3+
For details see a site such as https://css-tricks.com/snippets/css/using-font-face/ and https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<staticContent>
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="12:00:00" />
</staticContent>
</system.webServer>
</configuration>
I found that for some broswers (e.g. chrome, ie) I had to relaunch the browser for changed font files to be recognised (testing with .otf). For Android / iOS I had to close the geospatial portal tab and then open again in a fresh tab. Otherwise seemed to work fine.
I only tried once, but using the default internetexplorer option seemed to switch to using png. Using phantomjs and it printed using the svg content.
8. Test