This article introduces the matching rules for custom fonts using
@font-face through a problem location.
After using the style automatically generated by Blue Lake, there is a problem of bold on bold
font-weight: bold; with a bolder problem.
- Under Chrome on the macOS side, the style will not be bold and the style will be normal;
- Under Safari on the macOS side, the bold upper is bold, and the style is abnormal;
- Under Safari&Chrome on the iPhone side, the bold upper is bold, and the style is abnormal;
The writing in our custom font is:
The meaning of the above writing is: when
font-family is DINPro-Bold, and
font-style is normal, and
font-weight is normal, hit
Safari strictly abides by the above rules of font hits. When Safari sees the
.style_from_lanhu style, Safari’s processing is:
font-family: DINPro-Bolddirectly hits the
DINPro-Bold.wofffont, (DINPro followed by
font-weight: bold;and bold again, this is the reason for bold on bold.
font-weight: normal; in @font-face to
font-weight: bold; , after the modification
font-family: DINPro-Bold overlay
font-weight: bold; two conditions together, will hit the font.
As for why Chrome on the macOS side does not strictly follow the font hit rule, the reason is unknown.
Going a step further:
Why is the style code generated by sketch so concise, but how many lines does Blue Lake need to do?
Compare the difference
Personal speculation is that Blue Lake is compatible with another way of writing
@font-face , and it is also a more mainstream way of writing, that is,
On the other hand, when the custom font is not downloaded, it has a default bold effect, and the overall style will not be too obtrusive.
This article is reprinted from https://lvdawei.com/post/font-face-bugfix/
This site is for inclusion only, and the copyright belongs to the original author.