From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel Subject: Re: HTML-Info design Date: Tue, 30 Dec 2014 00:13:18 +0700 Message-ID: References: <871tnr1gqo.fsf@ferrier.me.uk> <83bnmvowdb.fsf@gnu.org> <83ppbanqhe.fsf@gnu.org> <87vbl2xigp.fsf@ferrier.me.uk> <83ioh2nlow.fsf@gnu.org> <87sig6xech.fsf@ferrier.me.uk> <83fvc5ni0u.fsf@gnu.org> <87k31fwwyv.fsf@ferrier.me.uk> <87bnmq9ibf.fsf@ferrier.me.uk> <87lhlrx5fc.fsf@building.gnus.org> <878uhrcr5l.fsf@building.gnus.org> <83sifzjflk.fsf@gnu.org> <87fvbyagaw.fsf@building.gnus.org> <83iogujvbq.fsf@gnu.org> <87tx0ee7rf.fsf@building.gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1419873231 19526 80.91.229.3 (29 Dec 2014 17:13:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Dec 2014 17:13:51 +0000 (UTC) Cc: Eli Zaretskii , Emacs developers To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 29 18:13:44 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y5dt1-00076X-HD for ged-emacs-devel@m.gmane.org; Mon, 29 Dec 2014 18:13:43 +0100 Original-Received: from localhost ([::1]:34190 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5dt0-0004Pb-Qs for ged-emacs-devel@m.gmane.org; Mon, 29 Dec 2014 12:13:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5dsn-0004PD-Rx for emacs-devel@gnu.org; Mon, 29 Dec 2014 12:13:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5dsj-0003Z2-Nw for emacs-devel@gnu.org; Mon, 29 Dec 2014 12:13:29 -0500 Original-Received: from mail-ig0-x234.google.com ([2607:f8b0:4001:c05::234]:36822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5dsd-0003Xi-L7; Mon, 29 Dec 2014 12:13:19 -0500 Original-Received: by mail-ig0-f180.google.com with SMTP id h15so11599919igd.1; Mon, 29 Dec 2014 09:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=SF/CnGLl2XY14HFp0i5D8FiHHLuZKbSDN5K8PcdJW24=; b=iAJ4mJpykIzfurraGXjIlx2xv0wVKzzR9ilhQhCEbYB/qolcMD7nvjTe1QuJMZTm9b xyAA/9wM+Ia/mOr1P7K6BaAlxezcRwQNdiWW8Nj2RJidiYLmQhksezndfi0cIu9DiI8B E4SdFTF6ye3UoQKPc/tO3qJfsHqRc6//ioRHFiDY7KGNTXLXvS/ARSm4MEm0CnfDnO6v F3Waxs/6PnMfT2AZ8ERw0CpUjgc8nb4KO3bpKRO/A655JNs4MS3tK4ZjZoZ+Kr5NwuXk HqhqdGNSJaRI2P04y9hud2pIf8BTDx8G8F8diK8byWeyV51FiPj10dKxPCMV2soE/d/m E70w== X-Received: by 10.50.44.104 with SMTP id d8mr47032652igm.9.1419873199207; Mon, 29 Dec 2014 09:13:19 -0800 (PST) Original-Received: by 10.107.48.82 with HTTP; Mon, 29 Dec 2014 09:13:18 -0800 (PST) In-Reply-To: <87tx0ee7rf.fsf@building.gnus.org> X-Google-Sender-Auth: ulfR1DQXfpWFt9h9670qJZFSTYU X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:180850 Archived-At: On Mon, Dec 29, 2014 at 10:32 PM, Lars Ingebrigtsen wrote: > Eli Zaretskii writes: > >> Fortunately, such a capability already exists, I think: see the >> function 'font-get-glyphs'. Does it solve your problem? If not, what >> API would you like to have? > > I've just looked at the doc string of that function briefly, and I'm not > sure how I would use that to do filling. I need to know the width a > text will take in the buffer, so that I know when to break the line and > start a new one. Is it now possible to write a function like > `pixel-region-width' that would say how much space the text will occupy? Naively, one might keep track of the remaining part of the paragraph being filled (initially the whole paragraph) and the remaining width in the current line (initially the whole column width). 1: Ask for glyphs for the remaining part of paragraph. 2: Find the last possible line breaking point such that the sum of glyph widths up to it is less than or equal to the remaining width. 3: Revalidate it by asking for glyphs for this part of paragraph. (In complex scripts, breaking the line might switch to a different presentation form.) If the sum of glyph widths is now greater than the remaining width, backtrack to the preceding possible line breaking point if it exists. 4: Layout the line, update the remaining part of paragraph, reset the remaining width of line, and repeat from step 1 if the remaining part of paragraph is not empty. (This intentionally omits almost all complexities related to RTL languages, and assumes that =E2=80=9Cfont-get-glyphs=E2=80=9D is smart enou= gh to return context-sensitive widths in complex scripts and to handle combining diacritics. It also assumes the existence of a predicate that tells if it a line break is possible after a certain position in a string. For many Western languages, that returns t after whitespace characters except for the non-breaking space. For CJK languages, it involves some context-specific logic. The German language might demand hyphenation logic roughly at the same time.) (Also, the Pango text rendering library implements this and probably much m= ore.)