Re: Download Roboto Font For Windows 10
George Bradley
Yesterday me and my colleague were collaborating on a same part of our project's UI and I noticed that she was changing correct paddings between text elements to incorrect one. When I asked why is she doing it, she answered that they were incorrect in the first place and she changed them to correct.
We've made a through-out testing and found out, that Roboto font has different heights on PC vs Mac. We've taken these screenshots while both co-editing this same file.
On a PC it looks like this:
After a long testing we found out that this difference was not consistent along different sizes of Roboto font. We made this comparison in a cloud file, both saved it as local file and created links with Design Specs.
I've marked font sizes that don't match with red color and on the left I marked the height difference with red. Here you can clearly see that the difference may differ from 0 to 2 pixels and it can be at the top, or at the bottom, or both.
This is a huge problem because I can't find any plausible workaround to make our Design Specs to be the same. It's very confusing both for designers and for developers. And after discussing this issue with our developers today, it appears that they already had a problem of different buttons being different heights that they had to fix. They thought I was just making small mistakes - it really hurts my reputation.
Adobe posts a lot of articles, videos and tutorials about design systems and enhanced collaboration. But we can't use neither of them because the same file opened in co-editing displays differently on PC vs Mac and the same components from our Libraries have different heights. This is not what I expect from a professional-grade software from such a huge developer as Adobe.
Thank you so much for waiting on the issue. After a long investigation into this issue and trying all the aspects to fix it. The team identified that the font engines on the 2 platforms return different values for this font, and it won't be fixed until we use the same engine on both platforms.
I understand your frustration and will definitely try my best to investigate on the issue. Thanks for sharing the details and screenshot along with the files. I have logged a bug for your issue so that our team can investigate on the issue. I will get back to you if they need any further details from you. I really appreciate your efforts on investigating the issue and writing to us.
These buttons were done before my coleague on Mac started working on our team, so developers used Design Specs links generated from windows for these buttons. It also alligns with our testing from original post - the in this case we use Roboto 14 in all our buttons:
I understand it could be a stumbling block for all of you. I checked the status of the bug and it looks the team is able to replicate the issue at their end and is working on fixing it. You will definitely see the improvements in the future releases of XD. I will also make sure to update the discussion as soon as it got fixed.
This issue may well lead us to ditch Adobe XD and use another product since it seems it has been a known issue for a long time with no fix in sight. We built out months worth of work during the pandemic on a Mac using Effra (Adobe Cloud Font) and now back in the office one day a week and on PC (using same Adobe Cloud Font) it shows the same issues as described here. Our files are unusable on PC and to stop using both Mac and PC systems to design is out of the question.
Cry for help! The display of the same document on the PC and Mac is significantly different. For this reason, it becomes absolutely impossible to work with colleagues. Look at the screenshots. What looks great on the Mac, on the PC changes the position, the display of font, linehight and it turns the layout into a pile of garbage.
Ultimately, XD coediting relies on the local, installed font. What we send across the wire is information about the font, and we load what you have installed locally. In this case, I would suspect that your local fonts are actually subtly different between the two operating systems, which won't get fixed in an XD update.
Thanks for sharing the info. Would you mind sharing the font with me so that we can test and investigate it? Please share the OS and XD versions of your machine along with the XD file. You may upload the file to a shared location such as Creative Cloud or Dropbox and share the URL with me.
Adobe's community forum is a bit of a mess - I was replying to HARSHIKA_VERMA, because in my thread she said they were able to replicate the issue and are working on a fix. But here they ask questions as if they have no idea of this issue.
We are sorry for the confusion. As Monterxz rightly pointed out, it does look like the similar issue that our team already investigated and find out the that the font engines on the 2 platforms return different values for this font and it won't be fixed until we use the same engine on both platforms.
We have the same issue, but in our case we are all using Macs, all using the same version of XD, and all using the same Adobe cloud font. Our working environment is identical but fonts / text boxes appear in different vertical positions on the page on different users computers. This makes collaboration impossible. I'd completely understand if we had different versions of fonts from various sources but these are all from Adobe.
As I use Roboto in more than one project (web sites and web apps, both desktop and responsive) I was thrilled to implement it immediately. The preview was clean and well spaced and all but while testing, I had to find out, that the Google Chrome (latest stable) on Windows has problems rendering the bold and bold-italic versions of the font.
The other font files seem to render correct and this one does so as well on Mac/Chrome but Win/Chrome has problems rendering Roboto bold and Roboto bolditalic for font sizes between 13px and 16px for a's and e's and between 10px and 14px for the i's.
If Roboto font is appearing distorted or narrower or whatever unexpected. Its because you have a version of the font in this case Roboto installed on your PC. Go to Control panel > Fonts and remove the roboto font installed on your system and happy you go. What is surprising however is the inability of Chrome to use the font from the web server and pick from the local system. Where as Edge and IE all use the font information from where its supposed to be used that being the web server.
If you have the latest version (v35 today) you can enable DirectWrite, which solved this issue for me.Just enter chrome://flags in the address bar, locate the Enable DirectWrite setting and click on Enable.
I'm using Roboto font widely through my web app. I'm developing on Linux and everything is fine, but then I checked if it looks the same on Windows, and it doesn't. In Windows-Chrome fonts are much bolder and ugly, also in Opera. Only in Firefox it looks normal (like on every browser in Linux). I have even made a fiddle and compared it on 2 browsers:
Is there anything I can do to fix this? Most people will be using my app on Windows-Chrome, and I don't like the font one bit. From the picture it doesn't look that bad, but in live app it makes a big difference.
Text rendering engines are very complex beasts with different algorithms and defaults from system to system. They won't ever give the same results except on high pixel density screens that make grid-fitting heuristics unnecessary.
Otherwise just accept they are different, and that it's fine for their users. Someone that spends its days in windows with windows-style text rendering is not going to complain your app is not Linuxy enough.
thank you for contributing to solve this problem. We are aware of this font behaviour and will try to fix it in future, but for now your temporary solution is simple and effective. As Piotr Glejzer said this is mainly the windows problem and we need to understand how to deal with it.
New computer, new system (before Debian 10 with TeX Live 2019 (?); now Debian 11 with TeX Live 2020). My old documents no longer render correctly. I should have Roboto Condensed for title and subsections, and Venturis for paragraph text. Compare good output (PDFs from old computer):
One thing that might be different from the old computer, is I installed Roboto for office use (LibreOffice etc.) via a Debian package instead of manually. But I guess that doesn't interfere at all with the TeX installation?
I am using pdflatex. If I add option sfdefault to package roboto, the title is correct, but now everything is in Roboto, including the paragraph text (which should remain in the serif). Another strange thing is that the serif is coming out significantly more condensed than in the old version (compare screenshots), perhaps it is related to the warnings in the log?
As pointed out in the comments, instead of just selecting with \robotocondensed, the change is to use \fontfamily\robotofamily\robotocondensed. Furthermore, I found that the condensed option to the roboto package creates a new problem where the other fonts become condensed as well; in this case the Venturis paragraph text. To fix this problem, remove the condensed package option, and redefine the section, subsection etc. headings with the titling package to ensure \robotocondensed is explicitly selected.
I imported my Sketch file and all the text is messed up. This seems to be because your do not support key Google fonts including Roboto. I cannot remove Roboto from my PC, it's used pretty much everywhere. What is the fix? Here's hoping this is one as otherwise I'll have to find a different tool.
b1e95dc632