PDA

View Full Version : AlegreyaSansSC-Bold.ttf on MacOS?



Varsuuk
May 16th, 2018, 03:48
I was looking at the console as I was working on some lua and came across a warning saying an alternative to "AlegreyaSansSC-Bold.ttf" was going to be used. Is there a way to fix this for the normal case? I "fixed" it for my ruleset by downloading the font from GitHub and placing it in my ruleset graphics/font directory.

It doesn't seem to cause any issues but I like a clean console, myself.

damned
May 16th, 2018, 08:44
You need to have the font for it to display...
I think Im misunderstanding what you are after maybe?

Varsuuk
May 16th, 2018, 13:07
Of course ;)

Yeah, apparently I didn’t have the font. My question is trying to find out if FG referencing is referencing a font it does not supply itself?

The path to the font is found in the coreRPG font file if I recall. Yet I didn’t see it in the fonts directory of coreRPG.

I just realized I didn’t check my Windows pc to see if same warning pops up. I will when I get home.

Like I said, I was able to download the ttf file, what is the correct workaround for coreRPG to find it other than unzipping coreRPG and rezipping with it. Does it find it if you place the ttf in some other Mac/Wine directory ? Not sure if FG looks at backup locations of not found where explicitly listed in the xml.

damned
May 16th, 2018, 13:32
I had always thought that FG only used fonts that were defined and included within FG itself but something Moon Wizard said recently makes me wonder of that is completely true...

Trenloe
May 16th, 2018, 14:03
AlgreyaSansSC-Bold.ttf comes in the CoreRPG ruleset. It’s in the usual place - graphics\fonts

Varsuuk
May 16th, 2018, 14:27
Okies... that’s weird... why does it report having to use another like it?

I thought maybe it was something in my ruleset but it occurred in AD&D Core as well (only 2 I tried) - but yeah, maybe somehow I caused it? I’ll try 5e once I get on the train (have my laptop) - I know for a fact thec coreRPG in rulesets die is the original pak. I never touched that file. I’ve unpacked it to a directory completely outside of the wine filesystem.

Trenloe
May 16th, 2018, 14:33
Have you checked your copy of CoreRPG.pak for the font file? In an earlier post you said it wasn't there.

Varsuuk
May 16th, 2018, 14:39
Yeah, about to do that. Tested in 5e same thing of course since all core based. This is a 3.3.5 version not updated this week not sure when last updated.

On this Mac was a newer install but running 3.3.3 since probably just tested new installer but forgot had 2 icons so still used first. That one has no warning.

Will look at the pak. If as expected it is missing will delete and update. The font was missing from my unpacked coreRPG but I thought maybe I fat finger erased it? Navigating folders since I never chose to erase it and what II said makes sense that FG includes all referenced fonts.

Varsuuk
May 16th, 2018, 15:03
1. Unpacked coreRPG from the ruleset directory. It was in the fonts directory (-Bold version)

2. Found out that it doesn’t show up (guess since warning) unless I have console already running. So, starting 5e or S&W neither report the font issue. When I start them and open /console and then do /reload, I see the attached.

Still need to update to see if changes. Not doing now since about to go into tunnels before Grand Central Station. Will update.

Hmm picture didn’t upload from phone not sure why.

Trenloe
May 16th, 2018, 15:11
Always remember there is a *BIG* difference between a warning and an error in the console. I warning is just that - a warning, something that may need to be looked at if there are issues.

That font is used by the "windowtitle" and "reference-page-header" FG font definitions. If the text in the Window titles and the reference manual page headers look fine, then there's really nothing to worry about.

Varsuuk
May 17th, 2018, 01:10
I know the diff between warnings and errors... in g++ I need to use -Werror compiler option (true story) to make the former the latter! (cos I do not allow any warnings in my server apps are work, bygumbydammit.)

But seriously, I know it is "ignorable" but I am a "why" guy. Why is it happening.
Verified it happens on my Linux box and my MacBook but not on my Windows native box. All were running the same versions. Just short of today's patch.

Weird. I'll compare Ref page headers and like later. Just wanted to point out it still happens.
Any non-Windows folks out there to verify for me? If so, just start er up as normal. Open the console - drag it to side so you can see it then type (or as per Damned, press your shortcut!) /reload and see if the warning pops up for you on the console.

This might have ALWAYS been this way but since I never have the console open, I didn't notice. Only because I started coding lua where I wanted debug messages did I start seeing this.

Moon Wizard
May 17th, 2018, 17:31
It's because of the way that font requests work in Windows. To request a TTF font through the Windows API, you give it a number of parameters, and the OS API decides which font you actually get from the fonts loaded in the OS. There is no option to specifically request a particular TTF file.

In FG, when using the TTF option for fonts, here is what happens:
* FG loads the TTF file included in the ruleset into OS font list. (file attribute of ttf tag)
* FG builds a font request using:
** Face name = font name you are requesting (name attribute of ttf tag)
** Height = height you are requesting (size attribute of ttf tag)
** Weight = Set to "normal" (unless "bold" attribute/subtag of ttf tag specified)
** Other default parameters:
*** Quality = CLEARTYPE_QUALITY;
*** OutPrecision = OUT_STROKE_PRECIS;
*** ClipPrecision = CLIP_STROKE_PRECIS;
*** PitchAndFamily = VARIABLE_PITCH;
* FG builds the font bitmaps based on the font returned by the OS.
* FG unloads the TTF file included by the ruleset

If the "face name" of the font returned by the OS does not match the "face name" requested, then you will get a warning. Usually, this is because the TTF file provided is for a particular style of font not included in TTF. (i.e. requesting normal font but TTF is very specific that it only includes bold version, etc.)

Regards,
JPG

Varsuuk
May 19th, 2018, 23:18
Moon, my main thing was:

1. To understand if others on Mac or Linux was saying the same warning if they /console then /reload
2. To ensure that was expected and not a bug.

I do notice in CoreRPG directory we have 2 TTF fonts and rest are FGF files. I attached the screenshot showing message for others wondering (because kept referring to it) - perhaps this happens because we are supplied a BOLD font and whatever is using it is requisition a non-BOLD font:

23534

Thanks,
Varsuuk

Moon Wizard
May 20th, 2018, 02:15
It even gets a little more complex, because specifying bold will also sometimes bold the font even if the font says it is a bold font. I think it depends on how the font was built.

Regards,
JPG

ll00ll00ll00ll
May 20th, 2018, 15:10
This won't be specifically relevant to the discussion at hand, but I can say that for my 20 years of dealing with font issues in a graphics production environment...any time I see a client include a folder full of .TTF fonts with their print job I cringe. .TTF files are notoriously buggy / susceptible to corruption. Since the far superior .OTF format has come about, our life in general has become much easier. The other misery of postscript fonts is something to be avoided as well (now each font is not one, but two files that can be corrupted!) Anyhoo... my 1.5 cents is that many of my font managers and RIP programs have displayed random errors for .TTF fonts over the years, but if the font is displaying and printing correctly, I stop asking questions and take it as a success.