Am 18.01.2019 um 12:04 schrieb jr:

>   and what about (SDL) platform agnosticism?  will we wind up with Windows + *NIX
> syntaxes?

That may be the case; we shall see. Remember that the whole concept of 
using fonts installed on the system is inherently leaving the terrain of 
platform agnosticism anyway, since a font installed on one system may be 
absent (or named differently) on another. You're inevitably leaving the 
territory of where you can pack up a scene and its accompanying files, 
carry it to another computer, unpack it there and expect it to render.

And if operating system FnordOS has no font names, and instead looks up 
installed fonts via attributes such as "serif", "monospaced" etc., then 
we have to get back to the drawing board and think up a useful but 
ultimately dedicated syntax for that particular platform.


> another reason is the "declared so" status, ie
> 
>>       TEXT_OBJECT:
>>         text {
>>           FONT_REFERENCE "Text_of_String"
>>           Thickness, <Offset>
>>           [OBJECT_MODIFIERS...]
>>           }
> 
>>       FONT_REFERENCE:
>>         FILE_FONT_REFERENCE |
>>         INTERNAL_FONT_REFERENCE |
>>         SYSTEM_FONT_REFERENCE
>>       FILE_FONT_REFERENCE:
>>         ttf "font_file.ttf/ttc"
>>       INTERNAL_FONT_REFERENCE:
>>         internal Font_Number
>>       SYSTEM_FONT_REFERENCE:
>>         sys "Font_Name" [bold] [italic]
>> This new option, SYSTEM_FONT_REFERENCE, is all this particular version
>> is about and all that I wanted to present in the post.
> 
> so SYSTEM_FONT_REFERENCE has been "set in stone" already while the other two
> types remain .. in flux.

In what sense would the other two remain in flux that wouldn't apply to 
SYSTEM_FONT_REFERENCE also?

(And no, I won't let font collection related changes count. It's 
probably more fitting to think of those as yet a fourth alternative to 
the above, which hasn't been added yet.)

The `cmap` stuff will apply to all of the above, if that's what you're 
talking about. As would be a "faux bold" parameter: Even if the font 
face is already bold by original design, a user might want to make it 
even bolder.


> but, since the 'text' is being reworked anyway, why do only half the job? 

The /implementation/ is being reworked, but the /syntax/ is being 
retained and just extended. That's why.

> I'd have thought that the <Offset>, for instance, should be be part of
> FONT_REFERENCE as it's about kerning.  and Thickness, in a sense, is redundant;
> a glyph's x + y extents are already provided, and subsequent scaling will be
> needed in almost all cases anyway.

FONT_REFERENCE is /exclusively/ about what "original design" to pick and 
start from. `<Offset>`, in contrast, is about how to /modify/ that 
original design, being an /addition/ to whatever advance width (and 
kerning, if applicable) the original font designer had envisioned.

Thickness could indeed be emulated by scaling, but it's there, so for 
the sake of backward compatibility we can't simply throw it away.


> have you considered using a dictionary?  one common-to-all key telling
> sys|int|ttf, and the remaining keys dependent, perhaps[*]?  the 'text' primitive
> could then be as simple as:
> text {
>     dictionary
>     "Text_of_String"
>     [OBJECT_MODIFIERS...]
> }

"One parameter to rule them all" - no, not a fan. We're not doing that 
for any other object either, so why should we for `text`?

That would, as a last consequence, lead to abominations like the following:

     #declare parameters = dictionary;
     parameters.center = <0,0,0>;
     parameters.radius = 1;
     parameters.texture = ...
     ...
     sphere { parameters }

Is that what you want? I highly doubt it.


We can discuss a syntax like this:

     #declare MyFont1 = font { sys "Times New Roman" italic }
     #declare MyFont2 = font { ttf "arialbd.ttf" }
     text { MyFont "Hello World" ... }

especially since it would come in handy for some other font-related 
features I envision for the future, such as accessing font metrics. But 
at the moment implementing such a thing would exceed my time and energy 
budget for font stuff, since introducing new variable types to the 
parser is (as yet) a high-level magic spell that drains a lot of mana.


For the time being, extending the existing syntax is the motto of the 
day. And since we need /some/ mechanism to tell POV-Ray whether to use 
the Regular or Bold face when specifying a font by family name, it is 
necessary to add /some/ parameter that is meaningless at best or 
confusing at worst when specifying a font by file name, and should 
therefore not be accepted in such a context.


And finally, if you need a "one parameter to rule them all" syntax, 
there's always the possibility to write a corresponding macro.

Post a reply to this message