David E. Ross wrote:
> Why can't this be resolved by users adhering to Appendix C of RFC 3986
Because in practice they don't.
-Boris
___
dev-tech-layout mailing list
dev-tech-layout@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-layout
On 10/10/2007 6:57 AM, Masayuki Nakano wrote:
> Jonas Sicking wrote:
>> Would it be at all possible to do different line wrapping for urls in
>> japanese (and similar) text, and in western languages?
>
> fm... It's interesting. But it seems that the hidden prefs are much
> better. And should it
On Oct 11, 2:57 am, Masayuki Nakano <[EMAIL PROTECTED]> wrote:
> Jonas Sicking wrote:
> > Would it be at all possible to do different line wrapping for urls in
> > japanese (and similar) text, and in western languages?
>
> fm... It's interesting. But it seems that the hidden prefs are much
> better
Masayuki Nakano wrote:
> Jonas Sicking wrote:
>> Would it be at all possible to do different line wrapping for urls in
>> japanese (and similar) text, and in western languages?
>
> fm... It's interesting. But it seems that the hidden prefs are much
> better. And should it be localizable pref? (
I filed bug 399321 for switchable URL breaker.
https://bugzilla.mozilla.org/show_bug.cgi?id=399321
--
Masayuki Nakano <[EMAIL PROTECTED]>
Manager, Internationalization, Mozilla Japan.
Personal Web Site (Written in Japanese): http://www.d-toybox.com/studio/
___
Jonas Sicking wrote:
> Would it be at all possible to do different line wrapping for urls in
> japanese (and similar) text, and in western languages?
fm... It's interesting. But it seems that the hidden prefs are much
better. And should it be localizable pref? (We may be able to use lang
attri
Boris Zbarsky wrote:
> Peter Weilbacher wrote:
>> But it drives me nuts when I paste URLs into the Bugzilla comment
>> field that they are wrapped. I want to turn that off. (When looking at
>> the comment after submission they are not wrapped any more, that makes
>> it even more confusing.) Am I
On 10/09/07 02:54, Masayuki Nakano wrote:
> hmm... I'm not sure it is problem. I think there are two patterns when
> you paste/write the URIs.
>
> 1. URI is a independent.
>
> I.e., URI is an only member of a paragraph. In western context, we use
> empty line for paragraph separator. So, the w
Peter Weilbacher wrote:
> But it drives me nuts when I paste URLs into the Bugzilla
> comment field that they are wrapped. I want to turn that off. (When
> looking at the comment after submission they are not wrapped any more,
> that makes it even more confusing.) Am I the only one annoyed by th
Peter Weilbacher wrote:
> On Mon, 8 Oct 2007 18:59:38 UTC, Masayuki Nakano wrote:
>
>> Peter Weilbacher wrote:
>>> Is there a way that I as a user can switch off file path/URI breaking? I
>>> find that very annoying. Is it planned to implement that or should I
>>> file an RFE?
>> If you are autho
Peter Weilbacher wrote:
> On Mon, 8 Oct 2007 12:17:16 UTC, Masayuki Nakano wrote:
>
>> I updated http://wiki.mozilla.org/Gecko:Line_Breaking
>>
>> The document explains the rules of current trunk simply.
>
> Is there a way that I as a user can switch off file path/URI breaking? I
> find that very
I updated http://wiki.mozilla.org/Gecko:Line_Breaking
The document explains the rules of current trunk simply.
# Should be moved to MDC?
Thanks.
--
Masayuki Nakano <[EMAIL PROTECTED]>
Manager, Internationalization, Mozilla Japan.
Personal Web Site (Written in Japanese): http://www.d-toybox.com/
Masayuki-san landed an update to the line breaking code last night.
The main impact is that we don't allow a break opportunity "too
close" (currently,. less than 6 characters away) from another break
opportunity unless it's at a whitespace boundary. This should make
thing
On Sep 3, 8:50 am, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
> Masayuki Nakano wrote:
> > We can remove date format checking. If it is less than 5, "/2007" and
> > "2007-" is breakable at before/after them.
>
> But I'd expect both "right-wing" and "left-wing" to be breakable.
Yes, but if we don't a
Masayuki Nakano wrote:
> er, I meant that "a statement about typical table cell widths on typical
> web pages".
I guess we're only talking about intra-word breaking, right? So whitespace can
still be broken on anytime?
In that case, you might be right. Let's give it a shot.
-Boris
_
Masayuki Nakano wrote:
> Boris Zbarsky wrote:
>> Masayuki Nakano wrote:
>>> And I think that your examples doesn't grow up the table cell width
>>> in actual web pages (and also doesn't overflow from fixed width box).
>>
>> I'm not sure I follow. Is that a statement about typical table cell
>> w
Boris Zbarsky wrote:
> Masayuki Nakano wrote:
>> And I think that your examples doesn't grow up the table cell width in
>> actual web pages (and also doesn't overflow from fixed width box).
>
> I'm not sure I follow. Is that a statement about typical table cell
> widths on typical web pages, or
Masayuki Nakano wrote:
> And I think that your examples doesn't grow up the table cell width in
> actual web pages (and also doesn't overflow from fixed width box).
I'm not sure I follow. Is that a statement about typical table cell widths on
typical web pages, or a statement about its fundamen
r should be backed out. But the
> URL/File path breaker is important for Japanese
> Marketing/Users/Designers. So, I cannot accept it.
>
> We need simple way for 1.9. And we should implement prioritized
> line-breaking in Mozilla2 (or later). Until then, we should take simple
apanese
Marketing/Users/Designers. So, I cannot accept it.
We need simple way for 1.9. And we should implement prioritized
line-breaking in Mozilla2 (or later). Until then, we should take simple
and low risk way.
And I think that your examples doesn't grow up the table cell width in
ac
Masayuki Nakano wrote:
> We can remove date format checking. If it is less than 5, "/2007" and
> "2007-" is breakable at before/after them.
But I'd expect both "right-wing" and "left-wing" to be breakable.
Perhaps we should look not only at the number of chars but also at what the
chars are or
Boris Zbarsky wrote:
> Masayuki Nakano wrote:
>> 'near' is defined as 6 characters now. Therefore, in Western word,
>> never breaking at first 6 characters and last 6 characters. i.e., if a
>> word is broken, it has 11 characters at least.
>
> Why 6? I actually think 4 would be a lot more reaso
Masayuki Nakano wrote:
> 'near' is defined as 6 characters now. Therefore, in Western word, never
> breaking at first 6 characters and last 6 characters. i.e., if a word is
> broken, it has 11 characters at least.
Why 6? I actually think 4 would be a lot more reasonable...
-Boris
I posted the new approach patch to bug 389056.
The general breaking rule is not changed from previous patch. But the
patch doesn't break at 'near' from start of word, end of word and
previous breaking point in western language context.
'near' is defined as 6 characters now. Therefore, in Wester
On 25 elo, 21:41, [EMAIL PROTECTED] wrote:
> It is interesting that, in addition to the ASCII hyphen-minus (U
> +002D), Unicode specifies even a "regular" hyphen (U+2010). It is
Now, here is an interesting bug. I wrote my previous message with a
text editor and copy-pasted it into the Google Grou
> GL: Non-breaking ("Glue") (XB/XA) (Non-tailorable)
> Non-breaking characters prohibit breaks on either side, but that
prohibition
> can be overridden by SP or ZW. In particular, when NBSP follows
SPACE,
> there is a break opportunity after the SPACE and NBSP will go as
visible
> space onto
fantasai wrote:
> Masayuki Nakano wrote:
>>
>> I don't take this idea in latest patch. But the latest patch fixes
>> many problems, e.g., the all testcases clears in:
>> https://bugzilla.mozilla.org/attachment.cgi?id=275972
>> # The chemical context will be broken.
>>
>> I hope that the latest pat
Masayuki Nakano wrote:
>
> I don't take this idea in latest patch. But the latest patch fixes many
> problems, e.g., the all testcases clears in:
> https://bugzilla.mozilla.org/attachment.cgi?id=275972
> # The chemical context will be broken.
>
> I hope that the latest patch is landed to trunk fo
[EMAIL PROTECTED] wrote:
> On 9 elo, 18:41, Masayuki Nakano <[EMAIL PROTECTED]> wrote:
>
>> https://bugzilla.mozilla.org/attachment.cgi?id=275972
>
> I think there is an error in the "Should break inside" list where the
> second item says that the combination SPACE+NBSP is breakable.
> According
On 9 elo, 18:41, Masayuki Nakano <[EMAIL PROTECTED]> wrote:
> https://bugzilla.mozilla.org/attachment.cgi?id=275972
I think there is an error in the "Should break inside" list where the
second item says that the combination SPACE+NBSP is breakable.
According to UAX 14, a non-breaking character pr
Boris Zbarsky wrote:
> [EMAIL PROTECTED] wrote:
>> Well, I'm not an expert on chemistry, so I'll have to refer to Alan
>> Wood who originally raised the issue with chemical names:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=95067#c78
>
> He raises an excellent suggestion: disallow breaks at '-
[EMAIL PROTECTED] wrote:
> Well, I'm not an expert on chemistry, so I'll have to refer to Alan
> Wood who originally raised the issue with chemical names:
> https://bugzilla.mozilla.org/show_bug.cgi?id=95067#c78
He raises an excellent suggestion: disallow breaks at '-' if this would result
in a 4
On 6 elo, 21:50, Masayuki Nakano <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Not breaking dates at all may be a good idea in itself, but I would
> > consider it more important to allow at least some kind of breaks in
> > long chemical names, such as '2-bromo-4,4-dichlorophenol'. It ma
Masayuki Nakano wrote:
> David E. Ross wrote:
>> On 8/5/2007 12:43 PM, Masayuki Nakano wrote [in part]:
4. DEGREE SIGN is not breakable if after character is character
class. But it's
still breakable if after character is numeric, for compatibility.
>>
>> Thus,
>> xxx xxx xxx 12
her the typographical benefits really overweight the danger of
> confusing some users.
>
> We should also keep in mind that the consistent line breaking
> principles in Latin scripts sometimes allowed characters to be used
> even in unconventional ways. For example, occasionally the
ader it's kind of natural to assume a
space there. The same goes for allowing breaks at curly backets,
semicolons etc. Thus, for each exception, we should consider carefully
whether the typographical benefits really overweight the danger of
confusing some users.
We should also keep in mind that th
David E. Ross wrote:
> On 8/5/2007 12:43 PM, Masayuki Nakano wrote [in part]:
>>> 4. DEGREE SIGN is not breakable if after character is character class. But
>>> it's
>>> still breakable if after character is numeric, for compatibility.
>
> Thus,
> xxx xxx xxx 126° 15' 32"
> near the end of
On 8/5/2007 12:43 PM, Masayuki Nakano wrote [in part]:
>>
>> 4. DEGREE SIGN is not breakable if after character is character class. But
>> it's
>> still breakable if after character is numeric, for compatibility.
Thus,
xxx xxx xxx 126° 15' 32"
near the end of a line could break as
Hi, all.
I posted new patch to bug 389056.
https://bugzilla.mozilla.org/show_bug.cgi?id=389056
https://bugzilla.mozilla.org/attachment.cgi?id=275308&action=diff
This patch has many fixes from feedbacks of this thread and other bugs.
> Masayuki Nakano (Mozilla Japan) 2007-08-05 02:31:20 PDT
>
[EMAIL PROTECTED] wrote:
[long mail snipped]
I pretty much agree with this e-mail. I wonder how hard some of this is to
implement... but it would be great if we can do it.
-Boris
___
dev-tech-layout mailing list
dev-tech-layout@lists.mozilla.org
htt
On 8/4/2007 11:08 AM, [EMAIL PROTECTED] wrote [in part]:
>
> In English, '$' is usually followed by a number ($20), while in some
> other languages, the currency symbol comes after the number ('20$' or
> '20 $' -- the latter example preferably with a no-break space). Also,
> in some languages, ca
On 2 elo, 20:19, fantasai <[EMAIL PROTECTED]> wrote:
> Masayuki Nakano wrote:
> > And we should also break after '&' and ';' or '='
>
> I don't see a problem with breaking after ';'. I can't recall how they're
> particularly relevant to URLs, but I also can't think of any cases where
> that would b
/linebr.html
Basically, the generic (language-independent) line breaking rules
should be as simple as possible while at the same time trying to
respect the conventions of natural languages. Thus, each character
should default to the kind of line breaking that was most likely
expected of it in its
/linebr.html
Basically, the generic (language-independent) line breaking rules
should be as simple as possible while at the same time trying to
respect the conventions of natural languages. Thus, each character
should default to the kind of line breaking that was most likely
expected of it in its
long organic chemical names. I'm not sure
there's a perfect solution there. ;(
> Note that if *authors* hope that the text should not broken around
> hyphen, they should use non-breakable hyphen (U+2011).
There's plenty of plain ASCII text we end up rendering (e-mail comes
[EMAIL PROTECTED] wrote:
> On Aug 4, 12:51 pm, Masayuki Nakano <[EMAIL PROTECTED]> wrote:
>> Japanese language can break everywhere except a few exceptions. I.e., we
>> are breaking words always. So, for us, the old rule (only breaks around
>> SPACE) is strange. Because some points (around punctuat
Boris Zbarsky wrote:
> David E. Ross wrote:
>> dates (e.g., 8/2/07, which I would usually write "2Aug07" to avoid
>> confusion with 8Feb07)
>
> Arguably, the '-' in 2007-08-02 should not break either. Nor should the
> '-' in "Examples 1-5". Nor in 2007-Aug-02.
'-', '/' and '=' are not brea
On Aug 4, 12:51 pm, Masayuki Nakano <[EMAIL PROTECTED]> wrote:
> Japanese language can break everywhere except a few exceptions. I.e., we
> are breaking words always. So, for us, the old rule (only breaks around
> SPACE) is strange. Because some points (around punctuations and
> parentheses), we ca
[EMAIL PROTECTED] wrote:
> On Aug 2, 10:12 pm, Masayuki Nakano <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>>> I really want to find out what the jp-critical need for linebreaking
>>> of Latin-1 text is.
>> we need to break URLs in most cases, therefore, I think, we should break
>> after
On Aug 2, 10:12 pm, Masayuki Nakano <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > I really want to find out what the jp-critical need for linebreaking
> > of Latin-1 text is.
>
> we need to break URLs in most cases, therefore, I think, we should break
> after '/' for path part of URLs.
David E. Ross wrote:
> dates (e.g., 8/2/07, which I would usually write "2Aug07" to avoid
> confusion with 8Feb07)
Arguably, the '-' in 2007-08-02 should not break either. Nor should the '-' in
"Examples 1-5". Nor in 2007-Aug-02.
-Boris
___
de
On 8/2/2007 10:19 AM, fantasai wrote [in part]:
> Masayuki Nakano wrote:
>> [EMAIL PROTECTED] wrote:
>>> I really want to find out what the jp-critical need for linebreaking
>>> of Latin-1 text is.
>> we need to break URLs in most cases, therefore, I think, we should break
>> after '/' for path pa
fantasai wrote:
> I don't see a problem with breaking after ';'. I can't recall how they're
> particularly relevant to URLs
The same way that '?' is, basically. I agree that this is a reasonable place
to
break, not only in URIs but in general.
-Boris
__
Masayuki Nakano wrote:
> [EMAIL PROTECTED] wrote:
>> I really want to find out what the jp-critical need for linebreaking
>> of Latin-1 text is.
>
> we need to break URLs in most cases, therefore, I think, we should break
> after '/' for path part of URLs. And also we should break after '\' for
[EMAIL PROTECTED] wrote:
> I really want to find out what the jp-critical need for linebreaking
> of Latin-1 text is.
we need to break URLs in most cases, therefore, I think, we should break
after '/' for path part of URLs. And also we should break after '\' for
windows file path too. And we sho
On Jul 27, 7:53 am, fantasai <[EMAIL PROTECTED]> wrote:
> There's a meta bug at
>https://bugzilla.mozilla.org/show_bug.cgi?id=206152
> but I think we need a little more centralized planning. Filing individual
> bugs isn't going to give us a coherent picture of what we're doing and what
> we wan
Masayuki recently landed bug 255990 (Characters below U+0100 not subject to
line-breaking rules), which has improved our line breaking in some cases
(we break after slashes!) and made it worse in others (we break 's/he'!)
https://bugzilla.mozilla.org/show_bug.cgi?id=255990
There&#x
Robert O'Callahan wrote:
Jean-Marc Desperrier wrote:
Well I'm not expert about that but I just had a look in the CSS2 norm,
and you can find this about using 'white-space: pre' :
http://www.w3.org/TR/1998/REC-CSS2-19980512/text.html#white-space-prop
[...] Lines are only broken at newlines in
Jean-Marc Desperrier wrote:
Shifting the topic a bit, currently using , and therefore also
text/plain, breaks a lot of i18n features. It's not nice when combining
character stop to combine [...]
Or when you can not use ZWJ (U+200D) in gmail composition window :
http://familleandries.iquebec.co
L. David Baron wrote:
We do? nsTextTransformer only seems to invoke it in the *Unicode*
functions, and https://bugzilla.mozilla.org/show_bug.cgi?id=255990 says
we don't.
Actually, I should have thought about that bug earlier. There, people
are advocating *always* using the JISX4051 rules. Tha
Robert O'Callahan wrote:
L. David Baron wrote:
On Thursday 2006-07-06 11:26 +1200, Robert O'Callahan wrote:
While working on some inline layout stuff, I've run into
nsJISx4051LineBreaker (which we use for all line breaking, actually).
We do? nsTextTransformer only seems to i
L. David Baron wrote:
On Thursday 2006-07-06 11:26 +1200, Robert O'Callahan wrote:
While working on some inline layout stuff, I've run into
nsJISx4051LineBreaker (which we use for all line breaking, actually).
We do? nsTextTransformer only seems to invoke it in the *Unicode*
func
On Thursday 2006-07-06 11:26 +1200, Robert O'Callahan wrote:
> While working on some inline layout stuff, I've run into
> nsJISx4051LineBreaker (which we use for all line breaking, actually).
We do? nsTextTransformer only seems to invoke it in the *Unicode*
func
While working on some inline layout stuff, I've run into
nsJISx4051LineBreaker (which we use for all line breaking, actually).
Apparently it's intended to work like this: if a word (delimited by
whitespace) contains at least one CJK character, then we apply JISX4051
rules to break w
On Thursday 2006-07-06 10:18 +1200, Robert O'Callahan wrote:
> Jean-Marc Desperrier wrote:
> > Well I'm not expert about that but I just had a look in the CSS2 norm,
> > and you can find this about using 'white-space: pre' :
> > http://www.w3.org/TR/1998/REC-CSS2-19980512/text.html#white-space-prop
Jean-Marc Desperrier wrote:
> Well I'm not expert about that but I just had a look in the CSS2 norm,
> and you can find this about using 'white-space: pre' :
> http://www.w3.org/TR/1998/REC-CSS2-19980512/text.html#white-space-prop
> [...] Lines are only broken at newlines in the source, or at
>
Justin Wood (Callek) wrote:
Robert O'Callahan wrote:
We break runs of CJK ideographs between certain ideograph pairs using
some standard algorithm. We suppress this breaking in runs that are
white-space:pre. On one hand, that means authors using white-space to
prevent breaking in regular text al
Robert O'Callahan wrote:
We break runs of CJK ideographs between certain ideograph pairs using
some standard algorithm. We suppress this breaking in runs that are
white-space:pre. On one hand, that means authors using white-space to
prevent breaking in regular text also have it working by analogy
We break runs of CJK ideographs between certain ideograph pairs using
some standard algorithm. We suppress this breaking in runs that are
white-space:pre. On one hand, that means authors using white-space to
prevent breaking in regular text also have it working by analogy in CJK
text. On the other
69 matches
Mail list logo
