freenode/#clim - IRC Chatlog
Search
2:57:55
slyrus1
perhaps one day I'll go back to beirc and that crap won't happen, but beirc has its own (lack of) stability issues.
4:42:48
slyrus1
So back to what I was saying this morning... If I define a presentation-method on a presentation-type that does not have a corresponding CLOS class, we get the "Cannot find type for specializer" style-warnings. Is this something we should try to fix in define-presentation-method or should we fix all of our code such that there are CLOS classes for our presentation-types?
4:43:26
loke
slyrus1: I think that only happens if you define the presentation-type and use it in the same file
4:43:55
slyrus1
That could be -- but it doesn't happen if you have the corresponding CLOS clas, as far as I can tell.
4:49:29
slyrus1
Hmm... I've got a case here where it happens reliably without the defclass def'n and no error with the defclass defintion.
4:49:55
slyrus1
but, nevertheless, we should be able to define presentation types without the CLOS class, from what I gather the spec is saying.
4:58:53
slyrus1
I think the :compile-toplevel and :load-toplevel distinctions between record-presentation-type and %define-presentation-type are bogus.
5:04:06
jackdaniel
the gist of this behavior is this: we need to be able to attach to CLOS class of that name if it exists
5:04:46
slyrus1
OK, but the eval-when stuff should be handled under the covers by the define-presentation-type stuff, no?
5:04:55
jackdaniel
that's why we expand it differently. if it does not exist (what may be determined at load time), then we have presentation type without backing it class
5:06:05
jackdaniel
I'm just saying that it is not bogus, just a little tedious (like defconstant on ccl)
5:06:36
jackdaniel
https://github.com/McCLIM/McCLIM/commit/91d0279165ed7359393b0ad249cb6206d1d6e2b5#diff-9c90cd104f8f00c4e1074bb8b2d676cf
5:07:31
jackdaniel
I've added in a meantime climb:font-face, climb:font-size and climb:font-fixed-width
5:10:36
loke
jackdaniel: Is FONT-CHARACTER-WIDTH really necessary? A character is often not representable as a glyph (i.e. it doesn't have a “width” on its own). Usually, in Unicode, a smallest displayable unit is what is called a “grapheme cluster”
5:12:13
loke
jackdaniel: my argument against that one is the same, so can't that one simply map to FONT-STRING-WIDTH (with a single-character string)?
5:12:17
jackdaniel
also font-string-width goes after advance-width, while character-width takes left and right bearning
5:13:00
loke
jackdaniel: But that's very Latin-centric. In most other languages, things are much more complex.
5:13:33
jackdaniel
in non-latin language there is not such a thing as width of a standalone character?
5:13:55
loke
Most of the time, you can't talk about a single “character” as something that has a visual representation. The way it's displayed depends on the other unicode characters that surround it (or are attached to it)
5:14:43
jackdaniel
character width is meant for a standalone characters. if there isn't such a thing, then you just wont call font-character-width
5:14:58
loke
Or, they kanda do, but the “character” in such languages are not represented by a single Unicode codepoint.
5:15:36
jackdaniel
it is like complining, that you can't call (char string 1), becase some languages doesn't have characters (?)
5:16:16
jackdaniel
there is a property in ttf for the glyph bounding box, I'm sure these languages are representable in this format
5:17:34
loke
“It is important to recognize that what the user thinks of as a “character”a basic unit of a writing system for a languagemay not be just a single Unicode code point. Instead, that basic unit may be made up of multiple Unicode code points. To avoid ambiguity with the computer use of the term character, this is called a user-perceived character. For example, “G” + grave-accent is a user-perceived character: users think of it as a single
5:17:34
loke
character, yet is actually represented by two Unicode code points. These user-perceived characters are approximated by what is called a grapheme cluster, which can be determined programmatically.”
5:18:43
jackdaniel
loke: I beliee you that in some alphabets calling font-character-width doesn't have much sense, but it does for what we perceive as character in common lisp
5:19:25
loke
Because a character in almost (all?) CL implementations is nothing more than a single Unicode codepoint.
5:19:36
jackdaniel
and I really don't see reason, why we shouldn't include it, especially that we have text-style-character-width which *is* in clim standard
5:19:57
jackdaniel
loke: so it will work for all characters which have a single unicode codepoint - that's good enough for me
5:20:16
loke
I tis, because CLIM was entirely latin-centric and had no concept of combining characters, or anything of the kind.
5:22:28
loke
The point is, that Unicode is complicated, but this is a well-researched topic and there are solutions that work. Implementing a new API to support characters and fonts and ignoring these topics is not the right thing to do.