[MPEG-OTSPEC] AHG meeting notes (and chat history) - Jan. 9, 2024

[Vladimir Levantovsky]

Dear all,

Thank you for your active participation in the AHG Zoom meeting yesterday.
Please see below a quick summary of the discussions and action items.

1. On "Beyond 64K glyph limit" proposed changes.
We reviewed and approved the proposal in general, with few pending updates
to be completed before the input submission deadline. Among more
substantial changes, we agreed that:
- 'dmap' table description would be removed from the current proposal. It
needs more work and will be discussed separately as part of the next AHG
meeting to be held after the upcoming SC29/WG3 meeting;
- new datatypes introduced as part of the VARC table description need to be
added in the updated "Data types" subclause 4.3 - an additional section in
the current proposal will address these changes;
- additional investigation and changes may be necessary (e.g.: BASE table,
etc.) - to be discussed at the next AHG meeting.

2. Two additional proposals.
After discussing both proposals (new feature variation, and opting out of
checksums) in details, we agree on the following:
- It makes sense to allow implementations to ignore checksums. The agreed
solution is to update the specification by declaring that if the checksum
value is zero, it can be ignored (and if the checksum computed value is
zero - no harm done). Skef will prepare an input contribution summarizing
the related spec changes.
- New Feature Variations proposal would benefit from additional discussions
- we agreed to continue the discussion at the next AHG meeting with the
goal to come to a resolution and review proposed spec updates at the next
AHG meeting, before the WG meeting in April.

3. New editorial changes - There were substantial editorial changes made in
OT 1.8.4 and later versions - most of them were based on public MSFT GitHub
submissions. Peter C. is working on an input contribution that would
summarize all remaining changes to be reviewed at the upcoming WG meeting
with the goal to synchronize the contents of the OT and OFF specifications
(as we've done in the past).

Please see Zoom chat notes attached.

FYI:
The input contribution deadlines for the upcoming WG meeting are as follows:
- Registration deadline: end of day CET on January 15;
- Submission deadline: end of day CET on January 17.
There will be a Font Break-out Group (BoG) meeting scheduled as part of the
WG meeting - per ISO rules, the participation in this BoG meeting is
limited to accredited WG delegates only. The AHG report will summarize AHG
activities conducted prior to the WG meeting, and will recommend that the
WG should accept input submissions.

Our next AHG meeting will tentatively be scheduled at the end of February,
after the new version of the Working Draft OFF is available for public
review.

Thank you all for your active participation and contributions to the work
of this AHG!
Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240110/fea19720/attachment.html>
-------------- next part --------------
10:16:31 From Hin-Tak Leung to Everyone:
	Just a caveat - variable length data/integer encoding schemes like utf8, while offers size savings, have a few disadvantages: mainly that data must be parsed in whole - this means elements cannot be binary searched (if stored sorted) or random-accessed.
10:18:27 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Renzhi is careing about the existing implementation (designed for the current or older OpenType spec) and ignoring the version number, I guess.
10:23:13 From suzuki toshiya (Hiroshima Univ) to Everyone:
	I think, PS/PDF renderers do not require to have OpenType layout. How about XPS renderer?
10:25:39 From Hin-Tak Leung to Everyone:
	My first thought about XPS is the same as PS/PDF, but then I think of the re-flow usage. So PDF readers are capable of re-flowing, an therefore needs the have opentype layout functionality.
10:26:07 From Hin-Tak Leung to Everyone:
	The re-flow functionality on adobe pdf reader on android is called 'crystal mode' or something.
10:26:44 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "The re-flow function..." with 🫨
10:27:08 From Hin-Tak Leung to Everyone:
	typically applications in the ebook space often offer text-reflow. So we are talking about epub usage.
10:28:08 From suzuki toshiya (Hiroshima Univ) to Everyone:
	I think the experts in this group may take it as one of the STB-like environment, if such PDF renderers cannot catch up with new spec.
10:29:51 From Hin-Tak Leung to Everyone:
	ebook readers aren't quite STB-like, but I agree that vendors probably can catch up with new spec.
10:31:18 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Replying to "ebook readers aren't..."
	
	I agree
10:31:24 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "ebook readers aren't..." with 🙏
10:32:03 From Ned Holbrook to Everyone:
	Considering that existing PDF documents would not have layout tables, I suspect this kind of functionality is implemented by identifying groups of glyphs and moving them around.
10:32:35 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "Considering that exi..." with 🫨
10:32:50 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Replying to "Considering that exi..."
	
	thanks
10:34:55 From Hin-Tak Leung to Everyone:
	Replying to "Considering that exi..."
	
	Yes, current implementations are probably some kind of in-app heuristics.
11:01:19 From suzuki toshiya (Hiroshima Univ) to Everyone:
	DMAP is designed for the multiple scripts/languages? It would be possible to support "MingLiU" and "PMingLiU" by GSUB technology, but...
11:02:10 From Hin-Tak Leung to Everyone:
	I see it as a lighter way of supporting MingLiU/PMingLiU than GSUB.
11:02:26 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "I see it as a lighte..." with 👍
11:06:00 From suzuki toshiya (Hiroshima Univ) to Everyone:
	For Pan-CJK font supporting both of SC/TC, using GSUB with language tag would be reasonable. But I'm not sure the original motivation of DMAP was such.
11:09:06 From Renzhi Li (MSFT) to Everyone:
	Many software do NOT apply GSUB
11:09:13 From Renzhi Li (MSFT) to Everyone:
	... for CJK
11:09:49 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "... for CJK" with 😵
11:10:52 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Thus, DMAP is better than GSUB?
11:13:38 From Ken Lunde to Everyone:
	My concern with the GSUB-only approach is that it operates at the GID level, whereas the dmap approach still interfaces with Unicode code points, which is how customers interface with such fonts.
11:14:47 From Renzhi Li (MSFT) to Everyone:
	Software ignoring GSUB are either...
11:14:51 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "Software ignoring GS..." with 😮
11:14:52 From Renzhi Li (MSFT) to Everyone:
	Not supporting GSUB at all.
11:15:02 From Renzhi Li (MSFT) to Everyone:
	Disabled GSUB on purpose for performance.
11:15:12 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "My concern with the ..." with 😮
11:16:06 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "Disabled GSUB on pur..." with 😮
11:16:11 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "Not supporting GSUB ..." with 😮
11:17:11 From Hin-Tak Leung to Everyone:
	Well, even current Skia has a set of drawing APIs for simple (non-shaped) text drawings, and GSUB look-up is a extra. So we aren't even talking about "old" software, but current Google owned ones...
11:17:30 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "Well, even current S..." with 😵
11:17:49 From Renzhi Li (MSFT) to Everyone:
	Shaping is SLOW
11:18:20 From Renzhi Li (MSFT) to Everyone:
	So people may disable OTL for "simple" scripts on purpose.
11:18:48 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "Shaping is SLOW" with 😅
11:18:53 From Hin-Tak Leung to Everyone:
	Actually I think people disable OTL by default, unless they think they need it :-).
11:19:23 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "So people may disabl..." with 😂
11:19:28 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "Actually I think peo..." with 😅
11:24:55 From Ned Holbrook to Everyone:
	Replying to "My concern with the ..."
	
	I would say that variation sequences in general argue for dmap.
11:25:14 From Takaaki Fuji to Everyone:
	See `uint16 referenceGlyph` of https://learn.microsoft.com/en-us/typography/opentype/spec/base#basecoord-format-2
11:26:31 From Renzhi Li (MSFT) to Everyone:
	Should we schedule a future meeting for "wide MATH"?
11:26:48 From Renzhi Li (MSFT) to Everyone:
	(We need to add people working on this table like Murray Sargent.)
11:35:52 From Hin-Tak Leung to Everyone:
	I think the ignore-checksum flag can go into the higher css spec instead?
12:03:00 From Ned Holbrook to Everyone:
	Need to switch to another meeting, sorry
12:04:29 From suzuki toshiya (Hiroshima Univ) to Everyone:
	Reacted to "Need to switch to an..." with 👋
12:06:26 From Yasuo Kida to Everyone:
	I can stay but thank you Vladimir.
12:17:12 From Bianca Berning to Everyone:
	Thank you everyone!