freenode/#clim - IRC Chatlog
Search
7:23:48
jackdaniel
so imho font-text-extents should return 12 values: pixel-wise width,ascent,descent,left,height (multiline text!) font-wise: width*,ascent*,descent*,height* and cursor-dx,cursor-dy which takes into account size and the last glyph (i.e new line)
7:27:56
jackdaniel
splitting into lines may happen at a higher level, but in order to provide correct boxes font-text-extents should take that into account
7:28:11
jackdaniel
unless you mean, that we should split lines on level of text-size and text-bounding-rectangle
7:29:44
jackdaniel
and what is a rationale behind splitting such computation between higher and lower abstraction?
7:31:43
jackdaniel
(in particular that means, that we'll duplicate algorithm for splitting by lines on both text-size and text-bounding-rectangle)
7:31:59
loke
jackdaniel: That it's better to have it at a higher level, since the splitting behaviour should be identical between all backends. I cannot think of any case where a backends needs different behaviour compared to another.
7:34:39
jackdaniel
in principle font-text-extents also will be the same for all backends (climb:font-glyph-* climb:font-* function-wise), other specializations will be only for speed
7:51:36
jackdaniel
as a side note: I can imagine interpretation, where supplied text is considered being a paragraph. In that case first line gets text-style-specific indent of the first line and/or cursor advance being bigger than line leading. but that's just a side-thought
7:54:28
jackdaniel
I'm going to write a default method for font-text-extents operating on other verbs in the protocol
7:54:49
loke
One related problem that I can think of is how to actually deal with word-wrapping. The problem is that to do wrapping you need to know the width of the “page”, but the text drawing functions do not have access to this information.
7:55:23
loke
(besides, it's impossible to actually acquire that information since you might be drawing to an output record and you don't know where said output record will be placed)
7:55:54
loke
So if WW is done at a higher level, I'm not sure I see why the lower level should have to deal with multiline.
9:08:50
jackdaniel
loke: you have added file Backends/CLX/bidi.lisp , I'm afraid it must be removed despite the fact I like the idea of having this functionality. original code license is GPLv3 thus not compatible with our codebase
9:10:29
jackdaniel
we'd have to write it from scratch and license under lgpl-2.1+ (or something more permissive)
9:12:55
loke
Indeed. I'll contact him. He seems to be pretty active on Mastodon so let's see what he says.
9:18:40
loke
jackdaniel: OK, I contacted him. If he doesn't agree I guess I can do a clean implementation based on the OAX
9:20:57
loke
I think using GPL for Lisp code is problematic, and most lispers seems to agree. LGPL (or Apache/BSD/MIT etc) are better.
9:22:04
loke
beach: Right, but if it includes GPL code, then the entirey of McCLIM can't be LGPL anymore.
9:25:07
jackdaniel
it doesn't mean that other parts of McCLIM code are GPLv3, but it makes no difference for someone who uses McCLIM as a library
9:26:01
loke
The LGPL is an extension of the GPL providing additional terms, those terms will not be applied to the pure GPL-licensed code of course.
9:26:36
loke
https://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing
9:26:43
jackdaniel
beach: I can read it again to find it for you, but that will have to wait for some free time, I'm busy at the moment
9:27:26
loke
“Code licensed under LGPLv2.x without the "any later version" statement can be relicensed if the whole combined work is licensed to GPLv2 or GPLv3”
9:31:25
jackdaniel
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you
9:31:53
jackdaniel
there is also paragraph about aggregation, but this is not an aggregation since we use the code as part of McCLIM (not package it)
9:35:52
loke
it could be argued that we don't trechnically use it, it's used by applications in order to be able to draw bidi text
9:36:53
jackdaniel
if you package bidi as a separate library, then we wouldn't be a subject of this license implication
9:37:41
jackdaniel
also, even if such interpretation would be defendable, that would be impolite towards the original author who (we need to assume that) were competent and knew what he were doing licensing his work
9:59:16
loke
Nothing has been decided yet. Also, it's not certain if I'll go to Paris, Beirut or both.
10:01:24
loke
beach: Oh, that kind of explains all the incredibly odd questions he's asked on c.l.l :-)
10:04:42
beach
He includes a wide spectrum from theoretical results through thorough experimentation, to implementation.
10:43:58
jackdaniel
http://ix.io/1oQ7 - this is how font-text-extents should behave. is this description complete and universal?
10:44:36
jackdaniel
I hope it will be useful also for vertically-oriented fonts and bidirectional text, so other layers of clim doesn't have to take care of it
10:58:58
jackdaniel
http://ix.io/1oQc (slightly modified version, bbox order modified, top argument added)
11:00:43
jackdaniel
top argument is necessary for completness (imagine vertical text starting from the bottom, then -ascent doesn't give us information necessary for the bounting box)