POV-Ray : Newsgroups : povray.beta-test : POV-Ray v3.8.0-x.freetype.2 : Re: POV-Ray v3.8.0-x.freetype.2 Server Time
14 Jun 2021 18:39:50 EDT (-0400)
  Re: POV-Ray v3.8.0-x.freetype.2  
From: jr
Date: 18 Jan 2019 06: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

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