Any interest in implementing these natively? Would be handy as syntax for combining Droid families, etc also. https://blogs.adobe.com/CCJKType/2012/05/breaking-64k-glyph-barrier.html https://blogs.adobe.com/CCJKType/2012/05/all-unicode-cfr.html Matching algorithms need to be changed slightly, but nothing major I would say. behdad
On Wed, Jul 25, 2012 at 6:13 AM, Behdad Esfahbod <behdad at behdad.org> wrote:> Any interest in implementing these natively? Would be handy as syntax for > combining Droid families, etc also.Yes, interesting idea to address the sort of that issue. I''ll have a look into it later. thanks for sharing the information. Cheers,> > https://blogs.adobe.com/CCJKType/2012/05/breaking-64k-glyph-barrier.html > https://blogs.adobe.com/CCJKType/2012/05/all-unicode-cfr.html > > Matching algorithms need to be changed slightly, but nothing major I would say. > > behdad > _______________________________________________ > Fontconfig mailing list > Fontconfig at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/fontconfig-- Akira TAGOH
Behdad, thank you for triggering the discussion on ISO CFR. Also I''m interested in the discussion about which existing library is the most appropriate place to support ISO Composite Font Representation, or, new library is required. In the earliest phase of ISO CFR discussion in ISO/IEC JTC1/SC29/WG11 font AHG, the object created by one CFR was expected to be looking like as a single font face object (and the client is not required to care if it is from single font file, or composite font). In my understanding, fontconfig does not provide a font face "object", so new thin layer above fontconfig & freetype is expected. Unfortunately, Werner Lemberg is now traveling and almost offline from the internet, so please wait August for his comment. Regards, mpsuzuki Akira TAGOH wrote:> On Wed, Jul 25, 2012 at 6:13 AM, Behdad Esfahbod <behdad at behdad.org> wrote: >> Any interest in implementing these natively? Would be handy as syntax for >> combining Droid families, etc also. > > Yes, interesting idea to address the sort of that issue. I''ll have a > look into it later. thanks for sharing the information. > > Cheers, > >> https://blogs.adobe.com/CCJKType/2012/05/breaking-64k-glyph-barrier.html >> https://blogs.adobe.com/CCJKType/2012/05/all-unicode-cfr.html >> >> Matching algorithms need to be changed slightly, but nothing major I would say. >> >> behdad >> _______________________________________________ >> Fontconfig mailing list >> Fontconfig at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/fontconfig > > >
Le Mer 25 juillet 2012 16:53, suzuki toshiya a ?crit :> Behdad, thank you for triggering the discussion on ISO CFR. > > Also I''m interested in the discussion about which existing library > is the most appropriate place to support ISO Composite Font > Representation, > or, new library is required. In the earliest phase of ISO CFR discussion > in ISO/IEC JTC1/SC29/WG11 font AHG, the object created by one CFR was > expected to be looking like as a single font face object (and the client > is not required to care if it is from single font file, or composite > font). > > In my understanding, fontconfig does not provide a font face "object", > so new thin layer above fontconfig & freetype is expected.The droid rules I posted recently are an example on how fontconfig can compose separate font files in a single font face from the application POV. Therefore I don''t think a new layer is needed, but the composing engine in fontconfig is clearly struggling to compose real-world font files, which overlap and are not nicely broken in separate script blocks http://pkgs.fedoraproject.org/gitweb/?p=google-droid-fonts.git;a=tree -- Nicolas Mailhot
On Wed, Jul 25, 2012 at 11:53 PM, suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp> wrote:> In my understanding, fontconfig does not provide a font face "object", > so new thin layer above fontconfig & freetype is expected.That''s true. after reading the paper, I''m thinking of similar. supporting the CFR in fontconfig only may needs a lot of changes in applications as well as fontconfig. if freetype has any hook to be filled in the missing piece, that would be easier. particularly to know where the real font is in, what the fallback font is if it''s missing and what the language is preferred too maybe. Aside from that we may need to add the postscript name in the cache to allow on the lookup since the CFR uses it rather than the family name. -- Akira TAGOH
On 08/10/2012 02:07 AM, Akira TAGOH wrote:> On Wed, Jul 25, 2012 at 11:53 PM, suzuki toshiya > <mpsuzuki at hiroshima-u.ac.jp> wrote: >> In my understanding, fontconfig does not provide a font face "object", >> so new thin layer above fontconfig & freetype is expected. > > That''s true. after reading the paper, I''m thinking of similar. > supporting the CFR in fontconfig only may needs a lot of changes in > applications as well as fontconfig. if freetype has any hook to be > filled in the missing piece, that would be easier. particularly to > know where the real font is in, what the fallback font is if it''s > missing and what the language is preferred too maybe.Actually I don''t agree. I think this fits better into fontconfig: on the matching / enumeration side of things, the CFR looks as if it''s one font, but it in fact expands to multiple fonts. It''s very similar to what ''sans'', or ''arial'' mean right now, or even ''Droid Sans''.> Aside from that we may need to add the postscript name in the cache to > allow on the lookup since the CFR uses it rather than the family name.That would be useful for PDF viewers regardless of this. behdad
Behdad Esfahbod wrote:> On 08/10/2012 02:07 AM, Akira TAGOH wrote: >> On Wed, Jul 25, 2012 at 11:53 PM, suzuki toshiya >> <mpsuzuki at hiroshima-u.ac.jp> wrote: >>> In my understanding, fontconfig does not provide a font face "object", >>> so new thin layer above fontconfig & freetype is expected. >> That''s true. after reading the paper, I''m thinking of similar. >> supporting the CFR in fontconfig only may needs a lot of changes in >> applications as well as fontconfig. if freetype has any hook to be >> filled in the missing piece, that would be easier. particularly to >> know where the real font is in, what the fallback font is if it''s >> missing and what the language is preferred too maybe. > > Actually I don''t agree. I think this fits better into fontconfig: on the > matching / enumeration side of things, the CFR looks as if it''s one font, but > it in fact expands to multiple fonts. It''s very similar to what ''sans'', or > ''arial'' mean right now, or even ''Droid Sans''.So, the CFR should be supported as yet another format of fontconfig''s config file, and still the application programmer should not expect as if the CFR does not simplify the requirement of the consideration of multiple fonts for a face name? If so, some translator from the CFR file to a file in fontconfig DTD would be the solution? Regards, mpsuzuki
On 08/24/2012 01:01 PM, suzuki toshiya wrote:> Behdad Esfahbod wrote: >> On 08/10/2012 02:07 AM, Akira TAGOH wrote: >>> On Wed, Jul 25, 2012 at 11:53 PM, suzuki toshiya >>> <mpsuzuki at hiroshima-u.ac.jp> wrote: >>>> In my understanding, fontconfig does not provide a font face "object", >>>> so new thin layer above fontconfig & freetype is expected. >>> That''s true. after reading the paper, I''m thinking of similar. >>> supporting the CFR in fontconfig only may needs a lot of changes in >>> applications as well as fontconfig. if freetype has any hook to be >>> filled in the missing piece, that would be easier. particularly to >>> know where the real font is in, what the fallback font is if it''s >>> missing and what the language is preferred too maybe. >> >> Actually I don''t agree. I think this fits better into fontconfig: on the >> matching / enumeration side of things, the CFR looks as if it''s one font, but >> it in fact expands to multiple fonts. It''s very similar to what ''sans'', or >> ''arial'' mean right now, or even ''Droid Sans''. > > So, the CFR should be supported as yet another format of fontconfig''s config > file, and still the application programmer should not expect as if the CFR > does not simplify the requirement of the consideration of multiple fonts > for a face name?Well, that would be the path of least change in the Free Software text stack.> If so, some translator from the CFR file to a file in fontconfig > DTD would be the solution?Or just plug it into fontconfig directly? Right now we don''t support adding families to the enumeration. Ie. you can''t write a configuration to add a pseudo family "MyFontCombo" to FcFontList output. We need such support for CFR. b> Regards, > mpsuzuki >
On Sat, Aug 25, 2012 at 1:37 AM, Behdad Esfahbod <behdad at behdad.org> wrote:> Actually I don''t agree. I think this fits better into fontconfig: on the > matching / enumeration side of things, the CFR looks as if it''s one font, but > it in fact expands to multiple fonts. It''s very similar to what ''sans'', or > ''arial'' mean right now, or even ''Droid Sans''.Sure. but only it is. the important part of this specification IMHO is, it provides a virtual font and has various parameters as a font, which allows to override something in an real font. given that we do support CFR in fontconfig, that would means we need to wrap up FreeType APIs or reimplement similar thing to take effects them in the worst case because we might not use FT_Face as is. this is why I think that may be better getting involved with FreeType or needing some hooks in FreeType to do what you said, which fontconfig is responsible. I think we need to update both for CFR.>> Aside from that we may need to add the postscript name in the cache to >> allow on the lookup since the CFR uses it rather than the family name. > > That would be useful for PDF viewers regardless of this.Yes, I think we have an RFE for that in bz. so that would be a good opportunity to support it. -- Akira TAGOH
On 08/27/2012 03:01 AM, Akira TAGOH wrote:> On Sat, Aug 25, 2012 at 1:37 AM, Behdad Esfahbod <behdad at behdad.org> wrote: >> Actually I don''t agree. I think this fits better into fontconfig: on the >> matching / enumeration side of things, the CFR looks as if it''s one font, but >> it in fact expands to multiple fonts. It''s very similar to what ''sans'', or >> ''arial'' mean right now, or even ''Droid Sans''. > > Sure. but only it is. the important part of this specification IMHO > is, it provides a virtual font and has various parameters as a font, > which allows to override something in an real font. given that we do > support CFR in fontconfig, that would means we need to wrap up > FreeType APIs or reimplement similar thing to take effects them in the > worst case because we might not use FT_Face as is. this is why I think > that may be better getting involved with FreeType or needing some > hooks in FreeType to do what you said, which fontconfig is > responsible. I think we need to update both for CFR.I agree. We wouldn''t be able to provide unified font metrics for the CFR, but other than that the rest should be easy to provide given our current APIs.>>> Aside from that we may need to add the postscript name in the cache to >>> allow on the lookup since the CFR uses it rather than the family name. >> >> That would be useful for PDF viewers regardless of this. > > Yes, I think we have an RFE for that in bz. so that would be a good > opportunity to support it.Right. behdad