Yesterdayme 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.
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.
GIMP uses the FreeType 2 font engine to render fonts, and a system called Fontconfig to manage them. GIMP will let you use any font in Fontconfig's font path; it will also let you use any font it finds in GIMP's font search path, which is set on the Font Folders page of the Preferences dialog. By default, the font search path includes a system GIMP-fonts folder (which you should not alter, even though it is actually empty), and a fonts folder inside your personal GIMP directory. You can add new folders to the font search path if it is more convenient for you.
Windows. The easiest way to install a font is to drag the file onto the Fonts directory and let the shell do its magic. Unless you've done something creative, it's probably in its default location of C:\windows\fonts or C:\winnt\fonts. Sometimes double-clicking on a font will install it as well as display it; sometimes it only displays it. This method will make the font available not only to GIMP, but also to other Windows applications.
To install a Type 1 file, you need both the .pfb and .pfm files. Drag the one that gets an icon into the fonts folder. The other one doesn't strictly need to be in the same directory when you drag the file, since it uses some kind of search algorithm to find it if it's not, but in any case putting it in the same directory does no harm.
3a8082e126