ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Yanrui Li <liyanrui.m2@gmail.com>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: Problem with "fontdata.cache" being set to "no" in font-def.lua
Date: Thu, 18 Jun 2009 11:03:43 +0800	[thread overview]
Message-ID: <c3f901470906172003h5770dec0i4e9749b1b9c043e5@mail.gmail.com> (raw)
In-Reply-To: <4A392537.7060802@wxs.nl>

2009/6/18 Hans Hagen <pragma@wxs.nl>
>
> Yanrui Li wrote:
>
>>> the cache option mentioned there is not meant for using, just for debugging
>>> (i.e. for myself)
>
>> I have printed the the shared descriptions with the following code fragment:
>>
>> function f4zhcn.pre_linebreak_filter (head, groupcode)
>>   for t in node.traverse(head) do
>>      if is_cjk_ideo (t) then
>>     texio.write_nl ('*** CJK Ideo ***')
>>      elseif is_cjk_puncts (t) then
>>     texio.write_nl ('*** CJK Punct ***')
>>     for k in pairs(font.fonts[t.font]) do
>>        texio.write_nl (k)
>>     end
>>      end
>>   end
>>   return true
>> end
>>
>> With "fontdata.cache = 'no'", I just got:
>
> as we cache fonts at the lua end we don't want interference at the tex end (not duplicate table creation); the no tells luatex not to manage a cache at the tex end (i.e. no free not creation)
>
> the "no" tells luatex not to keep a reference to the table it gets passed and when you then use font.fonts it will recreate a table from the data at the tex end and descriptions (and of course all other extra that i create and manage at the lua end is not available)
>
> at the lua end you can use fonts.ids[id] instead and then you will get a descriptions (and leave the fontdata.cache key untouched unless you want to waste memory and runtime)
>
> Hans
>
> ps. i will look into this bbox based compensation once we have a proper set of guaranteed correct standard cjk fonts in tex live and i've figured out a robust way to deal with it; i had code for it but threw it away out when i ran into conflicts with opentype features that do similar things and fonts that were inconsistent
>

Is there a way to provide some key parameters to users and allow them
to adjust these parameters in tex for the specific cjk fonts? For
Chinese fonts (because I just understand Chinese) I don't think those
opentype features is very useful. In general situation, we just need:

1. insert glue between Chinese glyph nodes for linebreak
2. reduce the spaces between Chinese punctuations
3. process protruding of punctuations which appear in margin.

If users can set up some parameters to control these features
according specific situation, maybe we do not need correct standard
CJK fonts. What I mean is that we can make an abstract layer for CJK
fonts. I don't know wether your plan is that or not.

--
Best regards,
Li Yanrui
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

  parent reply	other threads:[~2009-06-18  3:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-17  7:47 Yanrui Li
2009-06-17 14:45 ` Hans Hagen
2009-06-17 15:10   ` Yanrui Li
2009-06-17 17:17     ` Hans Hagen
2009-06-17 17:42       ` Yanrui Li
2009-06-18  3:03       ` Yanrui Li [this message]
2009-06-18 14:04         ` Hans Hagen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c3f901470906172003h5770dec0i4e9749b1b9c043e5@mail.gmail.com \
    --to=liyanrui.m2@gmail.com \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).