All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: [PATCH] multistring support in gui_label
Date: Wed, 17 Apr 2013 09:01:47 +0200	[thread overview]
Message-ID: <516E48DB.8070506@gmail.com> (raw)
In-Reply-To: <1720724.fd4NVO69U8@icedphoenix>

[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]

On 16.04.2013 11:04, Vladimir Testov wrote:

>> Please don't use // comments.
> O.k. I won't.
>> This code completely forgets the cases
>> when even the first word doesn't fit in the available space.
> 
> Mmm. It can handle this case actually.
> 
>> The code as whole breaks some unicode concepts like e.g. bidi stack.
> 
> Didn't get what you mean.
> 
>> Could you reuse the already available line-vreaking algorithm in
>> normal/term.c and normal/charset.c ? Since the line-breaking is
>> artificially disabled for labels it should require only minor
>> adjustments to be reenabled.
> 
> Yep! Here it is (patch included)!
> 
> Nevertheless, two problems appeared and I don't sure how exactly should I fix 
> them.
> 1) Handling of some long word. If this word is not first in line and it's 
> length is more than label's width
> then the length of the first fragment of the word will be counted as if it will 
> be drawn on the same line,
> but actually it will be printed on the next line.

Don't write any line-breaking at all yourself.

> 2) There is funny handling of UTF-8 symbols. Each symbol have "device_width" 
> parameter,
> which is used in calculation of string's length.

Where is it used? Show exactly. It must be some leftover code.


> How should I fix these problems?
> 1st one - for example, I can slightly update line-breaking mechanism.
> 2nd one - more interesting, harder. I suggest utf-8 printing mechanism 
> (charset.c unicode.c etc) should be remade. So symbol connections will be 
> counted in more intelligent way (e.g. while counting spaces - take into 
> consideration nearby symbols). It is interesting. :) I can do it. Would be 
> happy, if someone could give me some advices.

We don't do any kerning. No need to change algorithm.

> 
> Problem2.png 
> text = "@KEYMAP_LONG@"
> t is misprinted
> 
> Problem1.png
> text = "short short short 
> HereWeHaveSomeVeryLongWordSoItCannotBePrintedEntirelyOnOneLine"
> See how the line-breaking works.
> 
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

  parent reply	other threads:[~2013-04-17  7:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-16  9:04 [PATCH] multistring support in gui_label Vladimir Testov
2013-04-16 17:10 ` Andrey Borzenkov
2013-04-17  6:56   ` Vladimir Testov
2013-04-17  7:01 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2013-04-17  9:02   ` Vladimir Testov
2013-04-17 11:16     ` Vladimir Testov
2013-04-17 11:39     ` Vladimir Testov
2013-04-17 12:41       ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-04-23 11:58       ` Vladimir Testov
2013-04-23 16:26         ` [RFC][PATCH] " Vladimir Testov
  -- strict thread matches above, loose matches on Subject: below --
2013-03-22 15:58 [PATCH] " Vladimir Testov
2013-04-03  7:20 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-03-21 17:17 Vladimir Testov
2013-03-21 18:12 ` Gerard Butler

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=516E48DB.8070506@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.