• Not Answered

Special character inline bolding?

We have been doing some testing of special characters in the wiki and are seeing some odd rendering to the browser window.

In this example, characters with the acute and grave accents are bolded seemingly on their own. We are using an out-of-the-box Community 8.0.2 instance, with a couple of (seemingly) very disconnected CSS overrides. We added the statement

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

to the "Raw HTML Header", but that did nothing. This has us a bit baffled. Does anyone have any suggestions as to what to look at (and possibly what might "fix" that)? Short of imbedding special HTML characters, which is not a practical solution.

14 Replies

  • In reply to Phil Chouinard:

    Hi Phil,

    Could you link me to where on the site you are seeing this? I assume I'll have to impersonate a user of that language? Which language is that?

    Out of curiosity, if you delete the font-family "Open Sans" in the Chrome inspect window, does the font still render strange? I recall one of our other customers had a font issue identical to this and they were using a custom font. It would bold certain characters for their Polish words.

    Zac
  • In reply to Zac Elsik:

    Phil,

    After some investigating, I was able to determine this is a bug with our platform and the font that is currently being used. I've reported this to our team to take a look. I'll keep you updated as I hear back from them on a possible workaround (if any) and hotfix patch inclusion.

    Zac
  • In reply to Zac Elsik:

    Forgot to say thanks for this... just curious, have you heard or gotten any update regarding this?
  • In reply to Phil Chouinard:

    Hi Phil,

    Haven't heard anything yet on what the resolution will be. I'm asking again.
  • In reply to Phil Chouinard:

    Hi Phil, here's the official response from our Product Team on the matter.

    This is an issue with the bundled version of the Open Sans font provided by Google, the font's author. The same behavior can be seen using Google's own hosted copy of the font in their TypeCast preview tool.

    We've logged this as a bug.

    As a workaround, Font Squirrel's non-subsetted webfont kit for Open Sans does not exhibit this behavior and its versions of the light variant of Open Sans can replace Community 8's. Notably, their copy of OpenSans-Light-webfont.woff, can be renamed open-sans-300.woff and uploaded into the site theme configuration (Control Panel > Site Administration > Site Content > Site Theme > Supplementary Files)

    A copy of open-sans-300.woff has been attached.

    open-sans-300.woff.zip

  • In reply to Zac Elsik:

    After uploading that file, we are not seeing any difference -- special characters are still being bolded in text strings that have no bold attribution.
  • In reply to Phil Chouinard:

    Hi Phil,

    Can you link me to where you are seeing this on the site, and if you are impersonating a certain user (which one).

    I assumed you clicked "Save" at the bottom of the Site Theme page after uploading the file?

    You could also try clearing the cache at: http://communities.bentley.com/controlpanel/tools/ManageWidgets/DeveloperTools.aspx

    Zac
  • In reply to Zac Elsik:

    Can you also please share which browser and OS versions you're seeing this?
  • In reply to Zac Elsik:

    Link: 

    Not impersonating anyone... see this signed out AND signed in (even as a site admin)

    Clicked "Save" after upload, yes. Actually did that... twice... to make sure I didn't skip something by accident.

    Clearing cache through site admin page AND on browsers, yes (in fact, used new incognito/private sessions and same results).

    Browsers tried:

    • Firefox, v 31.0
    • Google Chrome, Version 36.0.1985.125 m
    • IE, v 11.0.10

    OS: Windows 7 Enterprise (but others using other Windows versions are seeing the same thing.

  • In reply to Phil Chouinard:

    It seems the version of open-sans-300.woff being served on the site is still the default (14 KB file size), and not the updated one attached in this thread (86 KB). The font was definitely uploaded to supplementary files, saved, and the site theme was saved? Additionally, screen.less still references the default version as well /cfs-filesystemfile/__key/themefiles/s-fd-3fc3f82483d14ec485ef92e206116d49-files/open_2D00_sans_2D00_300.woff (note the -fd-) . Has fonts.less in supplementary files been potentially edited to include hard-coded references?
  • In reply to Michael Monteleone:

    Michael Monteleone

    The font was definitely uploaded to supplementary files, saved, and the site theme was saved? 

    Yes, definitely. In fact, I just tried it again. You mention 86K filesize, I am seeing 82K. I uploaded to Supplementary Files (no errors), saved (no errors), went to site theme and saved (no errors). Flushed cache. No difference in the wiki article. Then went to download the file from the Supplementary Files page and it is (as you found) only 14K. I am not aware that we have done any customization (we are looking at straight OOTB for now... unless services did something along the way, not sure how to check for that).

  • In reply to Phil Chouinard:

    Any other ideas... this is getting a bit frustrating.
  • In reply to Phil Chouinard:

    Hi Phil,

    I checked the UAT site and it appears the font issue is no longer present for this page http://uat-communities.bentley.com/products/microstation/w/microstation_-_wiki_fr/11079.asb-test-3-0-fr-6-23-2014

    Here's a screenshot of the text I see:

    Is the issue now only present in the Live Prod environment?

    I tested on my local, fresh install of Community 8.0 as well. Here are the steps I took:

    1. Logged in as admin.
    2. Created a Forum Discussion with the special characters in the title and body of the post.
    3. Navigated to the Supplementary Files page of the Site Theme in Control Panel
    4. Under Supporting Files, I clicked the Upload button and chose the .woff file that Michael attached a few posts back. (mine was not blocked)
    5. I hit Save.
    6. Then I navigated to the Developer Tools page at /controlpanel/tools/ManageWidgets/DeveloperTools.aspx and hit the Clear Cache button.

    When I loaded up the forum discussion I created earlier and did a hard refresh (Ctrl + F5) then font was fixed.

    I'm pretty sure you did these exact same steps but with no success. It could be something related to the load-balanced environment that you have and it not accepting the new file and clearing the cache properly. Not quite sure here exactly.

    Zac

Related