freenode/#clim - IRC Chatlog
Search
6:25:13
beach
loke: You know a lot about Truetype fonts, right? I am trying to understand how to control the scaling and rendering process, in that I am trying to influence how glyphs are positioned in the pixel grid.
6:25:17
beach
I tried to draw some text using fractional coordinates, but the rendering looks the same as if I use integral coordinates, which I take to mean that the rendering is cached, and the coordinates are rounded.
6:25:27
beach
So for example, I would like to figure out how to take the oval shape representing a notehead, and make sure that the left and right edges are aligned with the pixel grid, presumably using perhaps a combination of scaling parameters (size and relative position) and drawing parameters (fractional coordinates).
6:25:28
beach
I can settle for scaling and relative position parameters and always use integer coordinates for drawing.
6:26:06
beach
I said "loke" but answers from anyone else having more information would be appreciated of course.
6:28:08
beach
I suppose this subject is related to "hinting", which I feel a bit queasy about, because whenever it is discussed, an environment with a static programming language, so they use a bytecode interpreted language for hinting.
6:58:21
beach
But I still need to understand how the rendering changes as a function of the :SIZE argument to MAKE-TRUETYPE-DEVICE-FONT-NAME.
6:59:44
beach
Clovetree will be much simpler than Gsharp in terms of rendering, because we now have anti-aliasing, Bezier curves, etc.
8:26:20
beach
Maybe the Fontforge manual will tell me what I need to know. I am actually playing around with Fontforge right now. It's kind of fun.
10:25:44
jackdaniel
general question about tracking-pointer: assume we have nested presentations: `board' and `field', when the context type is (or board field) and we move mouse over field (which is nested in board)
10:26:22
jackdaniel
:presentation clause should: a) be called only on the innermost presentation; b) should be called on all presentations (in which order) which are under the pointer and match the context type
10:35:55
jackdaniel
ck_: you've mentioned that :finish-on-release nil is not very useful, after some thought put into it I think I disagree
10:36:33
jackdaniel
while for two objects (drag A->B) finish-on-release makes more sense the alternative is better for dragging A->B->C->D
10:38:03
jackdaniel
while we do not support dnd-translators accepting more than one destination object I can imagine such translator
10:40:29
jackdaniel
also tester function for dnd tranaslator is pretty much useless for some cases without using climi::*dragged-object* undocumented variable
10:40:59
jackdaniel
because object is is bound to a dragged object and to destination object depending on pointer position
10:42:19
jackdaniel
probably we should fix it by having extended arglist for it (it begs for a macro where tester and translator have the same arglist)
10:45:23
scymtym
jackdaniel: i remember added a similar extension for a certain drag-and-drop operation in clouseau that i couldn't implement without it. let me see if i can find it
10:48:55
scymtym
probably this: https://github.com/scymtym/McCLIM/commit/07632fb7664a3fde874dd186e6883e951c07e73e
10:52:58
frgo
jackdaniel: I am using clx from sharplispers. T did not explicitly load any other package.
10:56:47
jackdaniel
scymtym: from a consistency point of view tester should be called with object bound to a dragged object (and presentation) and there should be extra arguments destination-object and destination-presentation (like for dnd-translator body)
10:57:30
scymtym
jackdaniel: sure. i'm not attached to particular names as long as the information is available
11:03:27
jackdaniel
this is certainly error from McCLIM (not CLX), for some reason it picks up x11 fonts (instead of ttf ones)
11:05:38
jackdaniel
frgo: in file Extensions/fonts/xrender-fonts.lisp function climb:text-style-to-font remove (call-next-method) to error right away and try again with that
11:08:14
scymtym
could this be another instance of https://github.com/McCLIM/McCLIM/issues/705 ? in that case, installing the font as described in the issue is a workaround
11:22:45
ck_
jackdaniel: while you're free-floating -- I put a pull request to CLX wrt. McCLIM/#637. I believe it is the correct place for the fix, but of course the buffering might just as well be done inside mcclim. You said the issue was 'important' so I'm pinging you with this here.
11:24:43
ck_
scymtym: I thought of that, and I don't think so, because from cursory looks to the xlib documentation, it is set at inception
11:24:48
jackdaniel
I'n 6m I'm taking over the little one so I won't manage to take a close look right away
11:25:26
scymtym
ck_: could you add a comment to that effect so someone reading the code doesn't have to worry?
11:26:05
ck_
scymtym: I will as soon as you (or anybody else) confirm my interpretation. I'm not very sure-footed with X11
11:27:52
ck_
ah, /that/ thing. Well, ok ... sure, if you think that's better. I personally don't think it reads too bad with the (or..)
11:30:14
scymtym
ck_: an unrelated nitpick: the closing paren on its own line was probably due to the end-of-line comment in line 362; adding another line allows having the closing paren on the same line
11:30:15
jackdaniel
hm, maybe nothing, I don't have strong opinion on that, but (or foo (setf foo …)) is a boilerplate. probably it is not justified for this one place
11:31:53
ck_
scymtym: sure. I'll hold back on the aesthetics until the functional part is greenlit, okay?
11:45:09
scymtym
ck_: it seems the only possibility would be https://tronche.com/gui/x/xlib/window/attributes/#XSetWindowAttributes.html , but it doesn't affect the depth as far as i can tell. so we may be in the clear
11:47:15
ck_
Thank you for checking. I tried to run the clx tests, but didn't get very far; I believe the documentation has diverged a bit from the code state
11:48:24
ck_
for example, in CLX/README.md, it tells me to load clx/demo/menu and then run xlib::just-say-lisp. But I can't find a function of that name in the sources
11:49:16
ck_
(it is "defined" in clx.texinfo, but I don't think that's the point of the exercise, is it?)
11:49:54
ck_
I would, but I'm late, I'm late for a very important date. Also I don't know what color cupcake I'd need to eat.
12:11:18
scymtym
jackdaniel: i played with ideas for the debugger: https://techfak.de/~jmoringe/debugger-ideas.png . what do you think?
12:24:34
ck_
I inspected some things this morning. Clouseau is great! Maybe I'll comment some matter-of-taste suggestions sometime.
12:29:11
frgo
jackdaniel: it turned out that sharplisper's CLX needed quite some tweeking to run on AllegroCL 10.1. I now get:
12:30:29
scymtym
ck_: i would be happy to hear them. i also have a few more improvements of my own planned
12:30:56
beach
If I draw a filled rectangle with coordinates that are not integers, should I get anti-aliasing? When I draw with 10 10 11.5 20 or something like that, I get a 2 pixel wide rectangle.
12:32:09
ck_
beach: there's a comment to that effect in graphics.lisp or medium.lisp. Short answer: no, no anti-aliasing -- but rounding.
12:32:18
frgo
Just as a side note: I am running AllegroCL in a docker container and am using Xquartz on macOX as the X11 Server
12:37:35
scymtym
i believe the clx-fb backend does provide anti-aliased rendering. it is slow, though
12:44:14
loke
beach: Your intuition is correct. The rasteriser only renders a glyph with pixel resolution.
12:45:50
loke
beach: Now, you are also right that hinting is one of the things that makes non-integral positions problematic.
12:47:19
loke
The Xrender backend could indeed copy glyph to a non-integral position. However, you really don't want that since Xrender simply copies a pre-rendered glyph (a bitmap, realy) to the screen. And if you specify the coordinate using subpixel coordinates, you'll end up with image-based antialiasing applied. This will not look pretty.
12:47:47
loke
For that reason, the font renderers (both TTF and FT) rounds the coordinate to the nearest integer position before drawing the stirng.
12:49:22
loke
The rasteriser generates an iage with an alpha-map that Xrender uses when blitting the glyph to the screen.
12:50:19
loke
Good would be if there was not rasterisation step, but that would be horrendously slow.
12:50:29
beach
The font I am using is a bit strange. A notehead, which is symmetric has its left side pixel aligned always, but the right side never seems to fit the grid for any integer point size.
12:51:24
beach
... so I would have liked for some hinting to be applied so that both sides are pixel aligned.
12:51:53
loke
The OSX renderer has three copies of each cached glyph (so a horizontal subpixel positioning of 1/3). But in the recent version of OSX they rolled that back and removed subpixel sampling, citing problems with the glyph cache as reasons, and arguing that high-dpi displays make it unnecessary
12:52:29
loke
beach: Hinting is part of the font. If it's your font, you can manually create such hints.
12:52:48
beach
Yes, and Fontforge seems to allow for it, but the manual says that hinting is then ignored by most renders.
12:54:35
beach
I use the default in McCLIM, but the font does not seem to have any hinting information in it.
12:55:06
loke
You might want to see how the FT renderer does it anyway. It uses subpixel sampling which may give you better result/
12:56:53
beach
I am confused. How is subpixel sampling related to hinting? And by "subpixel sampling" do you just mean a technique for anti-aliasing, or do you mean the equivalent of "subpixel anti-aliasing" where colors are used?
12:58:57
beach
I definitely don't want that. It looks awful on some of my monitors, and it would be impossible to use it with music rendering.