POV-Ray : Newsgroups : povray.beta-test : POV-Ray v3.8.0-x.freetype.2 Server Time: 19 Feb 2019 22:41:36 GMT
  POV-Ray v3.8.0-x.freetype.2 (Message 1 to 9 of 9)  
From: clipka
Subject: POV-Ray v3.8.0-x.freetype.2
Date: 17 Jan 2019 17:51:31
Message: <5c40c0a3$1@news.povray.org>
Now with support for installed fonts (currently Windows only):

https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.2

Syntax:

     TEXT_OBJECT:
       text {
         sys "Font Name" [FONT_STYLE_MODIFIER...]
         Thickness, <Offset>
         [OBJECT_MODIFIERS...]
         }

     FONT_STYLE_MODIFIER:
       bold | italic

where "Font Name" is the official name of a font (e.g. "Times New 
Roman") installed on the system. By default, the "regular" variant of 
the font will be selected; specifying `bold`, `italic` or both will 
instead select the bold, italic or bold-italic variant, respectively.


Note that `bold` and `italic` only work as expected if there are actual 
dedicated bold/italic font faces installed. POV-Ray will currently /not/ 
synthesize faux bold or faux italic outlines from the regular font face.

Also, `bold` and `italic` are limited to this new variant of the syntax, 
and are /not/ allowed with the classic `ttf` (or `internal`) syntax variant.


At present, the mechanism may produce surprising results if an exact 
match for the font name is not found.


As indicated above, the mechanism is currently only fully implemented 
for the Windows platform. The syntax /per se/ is accepted on other 
platforms as well, but no fonts will be found, leading to a parse error 
or, at this point, probably even a crash.

If anyone wants to pick up the glove of implementing the corresponding 
functionality for Unix, have a look at `platform/unix/osfontresolver.cpp`.


Post a reply to this message

From: jr
Subject: Re: POV-Ray v3.8.0-x.freetype.2
Date: 17 Jan 2019 21:15:01
Message: <web.5c40ef49fee67a6948892b50@news.povray.org>
hi,

clipka <ano### [at] anonymousorg> wrote:
> Now with support for installed fonts (currently Windows only):
> Syntax:
>      TEXT_OBJECT:
>        text {
>          sys "Font Name" [FONT_STYLE_MODIFIER...]
>          Thickness, <Offset>
>          [OBJECT_MODIFIERS...]
>          }
>
>      FONT_STYLE_MODIFIER:
>        bold | italic
> ...
> As indicated above, the mechanism is currently only fully implemented
> for the Windows platform. The syntax /per se/ is accepted on other
> platforms as well, ...

mildly confused..  does this mean that the syntax will depend on whether the
user chooses a 'sys' or 'ttf' font?  is the 'cmap {}' construct only for ttf's,
or has it been junked?  in all cases, will scene #version's less than 3.8
continue to work as before?


regards, jr.


Post a reply to this message

From: clipka
Subject: Re: POV-Ray v3.8.0-x.freetype.2
Date: 17 Jan 2019 21:57:49
Message: <5c40fa5d$1@news.povray.org>
Am 17.01.2019 um 22:10 schrieb jr:

> mildly confused..  does this mean that the syntax will depend on whether the
> user chooses a 'sys' or 'ttf' font?

(Oops, I forgot the "String_of_Text".
But I suspect you didn't even notice, otherwise you should be more than 
just "mildly" confused...)

Maybe it's easier to grasp if I present the syntax as follows:

     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.


> is the 'cmap {}' construct only for ttf's,
> or has it been junked?  in all cases, will scene #version's less than 3.8
> continue to work as before?

All of these other things require more work in the FreeType version, so 
no comment there until I even have a clearer picture myself where I'll 
end up with them.


Post a reply to this message

From: jr
Subject: Re: POV-Ray v3.8.0-x.freetype.2
Date: 17 Jan 2019 22:35:00
Message: <web.5c410263fee67a6948892b50@news.povray.org>
hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 17.01.2019 um 22:10 schrieb jr:
> > mildly confused..  does this mean that the syntax will depend on whether the
> > user chooses a 'sys' or 'ttf' font?
> (Oops, I forgot the "String_of_Text".
> But I suspect you didn't even notice, otherwise you should be more than
> just "mildly" confused...)
> Maybe it's easier to grasp if I present the syntax as follows:
>      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.
> > is the 'cmap {}' construct only for ttf's,
> > or has it been junked?  in all cases, will scene #version's less than 3.8
> > continue to work as before?
> All of these other things require more work in the FreeType version, so
> no comment there until I even have a clearer picture myself where I'll
> end up with them.

in fewer words, yes, you intend to introduce a syntax where 'FONT_REFERENCE'
(and perhaps more) will depend on the font's source.  folly, methinks..


regards, jr.


Post a reply to this message

From: clipka
Subject: Re: POV-Ray v3.8.0-x.freetype.2
Date: 18 Jan 2019 02:00:44
Message: <5c41334c$1@news.povray.org>
Am 17.01.2019 um 23:32 schrieb jr:

> in fewer words, yes, you intend to introduce a syntax where 'FONT_REFERENCE'
> (and perhaps more) will depend on the font's source.  folly, methinks..

And why would you say so?

When specifying a font via file name, you always get a single file, 
which typically(*) contains just one single font face; e.g. `arial.ttf` 
would give you the Arial Regular font face, while `arialbd.ttf` would 
give you the Arial Bold font face. So `text { ttf "arial.ttf" bold ... 
}" would make no sense.

When specifying a font via font name, you actually name the font family, 
e.g. "Arial", and have to provide additional information to select which 
font face of the family you want to load.


(*)As far as /font collections/ are concerned, i.e. files which contain 
multiple fonts, I'll still have to do some research to figure out what 
that even means and how they work. If it turns out that selectors like 
`bold` and/or `italic` are useful for font collections as well, the 
syntax for filename-referenced fonts will be extended accordingly. But 
not now.


As for /faux bold/ fonts - i.e. bold-looking fonts synthesized "on the 
fly" using mathematical transformations, rather than having been 
separately constructed by a font designer - if I implement such a 
feature I'll probably provide a separate syntax for it, to give the user 
full contropl over the magnitude of the effect. Such syntax would be 
available independent of the font source, so you could e.g. reference 
the bold variant of a system font and synthesize an even bolder font 
from it.

As for /faux italic/ (which is actually a misnomer, since such a font 
would be an oblique rather than italic font) such an effect can already 
be achieved using a shearing transformation on the resulting object.


Post a reply to this message

From: jr
Subject: Re: POV-Ray v3.8.0-x.freetype.2
Date: 18 Jan 2019 11:15:01
Message: <web.5c41b1ebfee67a6948892b50@news.povray.org>
hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 17.01.2019 um 23:32 schrieb jr:
> > in fewer words, yes, you intend to introduce a syntax where 'FONT_REFERENCE'
> > (and perhaps more) will depend on the font's source.  folly, methinks..
>
> And why would you say so?

folly ("foolishness")?  for one, that is my end-user-perspective reaction to
this course of action.  a syntax which depends on the font's source may "get in
the way" for scenes where font selection happens at runtime.  it would also add,
unnecessarily IMO, the need having to remember and deal with the variation(s).
 and what about (SDL) platform agnosticism?  will we wind up with Windows + *NIX
syntaxes?

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.

but, since the 'text' is being reworked anyway, why do only half the job?  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.

my impression of the whole thing is very much .. not thought through.

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...]
}

[*] ideally each type ignores not-applicable keys.


regards, jr


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: POV-Ray v3.8.0-x.freetype.2
Date: 18 Jan 2019 13:50:01
Message: <web.5c41d8d3fee67a69d8bb6cc30@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Now with support for installed fonts (currently Windows only):
>
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.2
>
> Syntax:
>
>      TEXT_OBJECT:
>        text {
>          sys "Font Name" [FONT_STYLE_MODIFIER...]
>          Thickness, <Offset>
>          [OBJECT_MODIFIERS...]
>          }
>
>      FONT_STYLE_MODIFIER:
>        bold | italic

I really like this!!! And at long last something that makes the painful process
to move POV-Ray to AGPL look like it was worth it!

Thorsten


Post a reply to this message

From: clipka
Subject: Re: POV-Ray v3.8.0-x.freetype.2
Date: 18 Jan 2019 14:39:11
Message: <5c41e50f$1@news.povray.org>
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

From: jr
Subject: Re: POV-Ray v3.8.0-x.freetype.2
Date: 18 Jan 2019 17:35:06
Message: <web.5c420d0dfee67a6948892b50@news.povray.org>
hi,

thank you for the detailed/informative reply.

clipka <ano### [at] anonymousorg> wrote:
> >   and what about (SDL) platform agnosticism?  ...
>
> That may be the case; ... 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.

unfortunate but true.

one (Tcl's) approach is to have platform and architecture stuff in a single
(associative) array.


> The `cmap` stuff will apply to all of the above, if that's what you're
> talking about.

that was part of my concerns.


> "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:
>      ...
>      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.

personally, I'd like that.  (particularly if it were a {key value} style list.
:-))

and yes regarding the import/value of remaining consistent (across objects).


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


regards, jr.


Post a reply to this message

Copyright 2003-2008 Persistence of Vision Raytracer Pty. Ltd.