Baseline API

[ebraminio]

Following #418, maybe we need some discussion on how the API should be shaped

DirectWrite exposes https://github.com/apitrace/dxsdk/blob/master/Include/dwrite_1.h#L1461-L1491 which may is good starting point but we should consider variation and bsln also.

Maybe this,

HB_EXTERN hb_bool_t
hb_ot_layout_get_baseline (hb_font_t       *font,
			   hb_baseline_t    baseline,
			   hb_bool_t        is_vertical,
			   hb_bool_t        is_simulation_allowed,
			   hb_script_t      script,
			   hb_language_t    language,
			   hb_codepoint_t  *glyph /* IN/OUT.  May be NULL. */,
			   int             *result);

Why not hb_face_t? Because BASE now supports variations so better to take a hb_font_t instead.

Thus the result can or should be scaled by hb_font_t's ppem.

glyph may is extra, it can output referenceGlyph from BASE, or, act as input for bsln lookup

Or may an incorrect idea, how about taking a hb_buffer_t instead so API wouldn't need for passing script and language and input glyph can be used from a shaped hb_buffer_t buffer.

And do we have facilities for base simulation? If not lets remove this now.

About hb_baseline_t,

/* DirectWrite:
    /// The Roman baseline for horizontal, Central baseline for vertical.
    DWRITE_BASELINE_DEFAULT,
    /// The baseline used by alphabetic scripts such as Latin, Greek, Cyrillic.
    DWRITE_BASELINE_ROMAN,
    /// Central baseline, generally used for vertical text.
    DWRITE_BASELINE_CENTRAL,
    /// Mathematical baseline which math characters are centered on.
    DWRITE_BASELINE_MATH,
    /// Hanging baseline, used in scripts like Devanagari.
    DWRITE_BASELINE_HANGING,
    /// Ideographic bottom baseline for CJK, left in vertical.
    DWRITE_BASELINE_IDEOGRAPHIC_BOTTOM,
    /// Ideographic top baseline for CJK, right in vertical.
    DWRITE_BASELINE_IDEOGRAPHIC_TOP,
    /// The bottom-most extent in horizontal, left-most in vertical.
    DWRITE_BASELINE_MINIMUM,
    /// The top-most extent in horizontal, right-most in vertical.
    DWRITE_BASELINE_MAXIMUM,
    */
/* CoreText:
   kCTBaselineClassRoman, kCTBaselineClassIdeographicCentered,
   kCTBaselineClassIdeographicLow, kCTBaselineClassIdeographicHigh,
   kCTBaselineClassHanging, kCTBaselineClassMath, kCTBaselineReferenceFont,
   kCTBaselineOriginalFont, kCTBaselineClassAttributeName, kCTBaselineInfoAttributeName,
   kCTBaselineReferenceInfoAttributeName */

May this is what we can offer as our enum,

typedef enum {
  HB_OT_BASELINE_HANGING = HB_TAG('h','a','n','g'),
//   HB_OT_BASELINE_ = HB_TAG('i','c','f','b'), what is correct name for it?
//   HB_OT_BASELINE = HB_TAG('i','c','f','t'), what is correct name for it?
  HB_OT_BASELINE_IDEOGRAPHIC = HB_TAG('i','d','e','o'),
//   HB_OT_BASELINE = HB_TAG('i','d','t','b'), what is correct name for it?
  HB_OT_BASELINE_MATH  = HB_TAG('m','a','t','h'),
  HB_OT_BASELINE_ROMAN = HB_TAG('r','o','m','n')
} hb_baseline_t;

Just like hb_script_t, or better to not expose it? But it is incomplete, where should I look for others? For example CanvasRenderingContext2D.textBaseline exposes "top" || "hanging" || "middle" || "alphabetic" || "ideographic" || "bottom" what are their respective tags?

[eroux]

Thanks for starting the discussion!

I think the tags exposed by textBaseline would be exposed by a higher level library using harfbuzz.

But it's really unclear to me how high level harfbuzz should be in that area. For instance we could imagine an API where, when shaping a buffer, it's possible to give harfbuzz the various values of the baselines in a context and imagine the following workflow:

• firefox determines in some way that it wants to align characters using the hang baseline and it wants the hang baseline to be at coordinate y
• firefox calls harfbuzz asking please shape this text with the constraint of having the hang baseline at coordinate y

would such an API make sense? It would make it more complex but it would also ease the use of BASE by other libraries... what do you think?

[ebraminio]

Considering bsln and its per glyph baseline lookup which needs buffer, this specially can make sense but I guess Behdad has another POV. This however doesn't cover the case of the need of actual baseline value that desktop publisher software may need I guess.

…

On Thursday, November 1, 2018, Elie Roux ***@***.***> wrote: Thanks for starting the discussion! I think the tags exposed by textBaseline would be exposed by a higher level library using harfbuzz. But it's really unclear to me how high level harfbuzz should be in that area. For instance we could imagine an API where, when shaping a buffer, it's possible to give harfbuzz the various values of the baselines in a context and imagine the following workflow: - firefox determines in some way that it wants to align characters using the hang baseline and it wants the hang baseline to be at coordinate y - firefox calls harfbuzz asking please shape this text with the constraint of having the hang baseline at coordinate y would such an API make sense? It would make it more complex but it would also ease the use of BASE by other libraries... what do you think? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1345 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAy3wQDciSHme7DfLA6bRbIOk992RE1sks5uqrwKgaJpZM4YFy1v> .

[behdad]

No per-glyph. 'bsln' is dying so let's just design for BASE.

[behdad]

HB_EXTERN hb_bool_t
hb_ot_layout_get_baseline (hb_font_t       *font,
			   hb_baseline_t    baseline,
			   hb_bool_t        is_vertical,

hb_direction_t.

  	   hb_bool_t        is_simulation_allowed,

Ugh. Remove. We always simulate if not found, but return false.

  	   hb_script_t      script,
  	   hb_language_t    language,
  	   hb_codepoint_t  *glyph /* IN/OUT.  May be NULL. */,

Remove.

  	   int             *result);

hb_position_t.

[behdad]

For enum name and members, prefix with hb_ot_layout_baseline please.

[ebraminio]

Without considering bsln I guess there won't be much debate left here so closing in favor of #1347