| | <<<Back 1 day (to 2016/02/21) | 20160222 |
| tor8 | sebras: 'em' is an abstract unit of font size. it has no relation to any actual features of the font, other than being used to scale the font from its 'unit' size. | 10:15.37 |
| | ex is 0.5 * em | 10:15.54 |
| | and line-height in css is defined in terms of 'em' (i.e. line-height: 120% is 'em' * 1.2) | 10:17.43 |
| | sebras: in freetype there is a face->units_per_EM scale which is typically 2048 for truetype and 1000 for postscript fonts | 10:20.23 |
| | this is used to scale fonts; the outlines are scaled first by dividing by this units_per_EM and then multiplied by the font size (i.e. 'em') | 10:21.02 |
| | how big an ascender is has no actual relation to this; there are other values in the font header that say how tall they are | 10:22.03 |
| HenryStiles | kens: we got a signed release from michael (ram file system) and the money should go out this week. Be nice if the cash was incentive to do more work, we'll see | 15:08.18 |
| kens | I htnk he does other stuff nowadays but it'll be good to have that cleared up | 15:08.41 |
| HenryStiles | kens: by the way can I have a few test files for the pcl->pdf/a. I'm changing a good amount of the pl code and don't want to much that up. | 15:09.34 |
| | s/much/muck | 15:09.46 |
| kens | OK I'll mail something to you | 15:09.52 |
| HenryStiles | chrisl: I'm free all day today to talk about pcl. | 15:10.33 |
| chrisl | HenryStiles: I looked at the initialisation code, and it's not going to be easy to do what you wanted at all | 15:11.13 |
| HenryStiles | chrisl: what did I want to do ? I've given up on so many things I can't keep them straight ;-) | 15:12.00 |
| chrisl | HenryStiles: you wanted the interpreter to pass the allocator in for FAPI to use | 15:12.28 |
| HenryStiles | chrisl: oh that ...doesn't really matter I now pass in the chunk manager, and it wraps that, which results in the same thing you have now. | 15:13.34 |
| chrisl | HenryStiles: I was thinking we could change it so if only wraps the allocator if it is not already a chunk allocator instance | 15:14.17 |
| | s/if/it | 15:14.24 |
| HenryStiles | chrisl: you could but the output is the same right? | 15:14.58 |
| chrisl | HenryStiles: No, I think at the moment we'll end up with a new chunk allocator instance "on top of" the previous one | 15:15.55 |
| HenryStiles | chrisl: but this is used by gs no? So you've basically disable gc for everything that uses fapi ... | 15:16.02 |
| chrisl | HenryStiles: We can't use gc memory for fapi | 15:16.23 |
| | Freetype and UFST really don't expect allocations to move around | 15:16.53 |
| HenryStiles | chrisl: how did it work before that change? | 15:17.49 |
| chrisl | HenryStiles: it just used non gc memory | 15:18.07 |
| | HenryStiles: Using the chunk allocator was a performance gain, not a bug fix | 15:19.15 |
| HenryStiles | chrisl: right. I can easily fix it not to wrap twice, but it also seemed consistent to leave it as is. You have a separate allocator for fapi | 15:22.21 |
| chrisl | HenryStiles: That's fine by me. | 15:23.19 |
| tor8 | Robin_Watts: got a minute? | 15:24.09 |
| HenryStiles | chrisl: now reading the logs kens said he has made progress getting gc out of pdfwrite but you thought this was hopeless. devices free of gc really change the direction of the language switching project. | 15:25.16 |
| chrisl | HenryStiles: Then other thing was something I want to do. At the moment PCL passes disk fonts to FAPI in a memory buffer, that FAPI copies. I'd like to add a FAPI call to allocate the font buffer, and have PCL read the font file straight into that (so we avoid a duplicate memory allocation, and a buffer copy) | 15:25.16 |
| | HenryStiles: *NOT EVEN REMOTELY THE SAME THING*!!!!!!!!! | 15:25.47 |
| kens | pdfwrite should no longer rely on GC. I say 'should'..... | 15:26.31 |
| tor8 | Robin_Watts: on tor/script there is a new mutool -- run. it runs a javascript with bindings similar to the JNI ones. | 15:26.36 |
| chrisl | kens: But the *device* is still allocated in gc memory | 15:26.49 |
| kens | Oh yeah, different problem | 15:27.01 |
| tor8 | doing the bindings, I've stumbled across the fz_rect argument to several of the fz_clip_* functions | 15:27.11 |
| | but that rect looks like it's redundant | 15:27.21 |
| | so I wonder if we can just remove it | 15:27.30 |
| | or make sure we can leave it null and recompute in the fz_clip_xxx wrappers, and not expose it in the jni/js bindings | 15:28.04 |
| chrisl | As we have discussed at least five times before: devices (including pdfwrite) are entirely free to use whatever memory allocator they like for their *own* memory, but the device object itself still has to be in gc memory. | 15:28.09 |
| HenryStiles | chrisl: I'm certainly in favor of the change not to copy the font data. | 15:38.04 |
| chrisl | HenryStiles: I may have had a better idea on that - I'll probably look at it properly on the way to the staff meeting | 15:38.48 |
| HenryStiles | chrisl: I've always lumped together the allocator the device uses and the devices allocator as one huge problem. Actually I thought the largest obstacle to having a shared language switch device was pdfwrite and high level devices. Indeed the current LS environment works to some extent with raster devices not but not pdfwrite. | 15:43.25 |
| chrisl | HenryStiles: I'm not at all sure a) why pdfwrite should (now) be an exception, and b) how allocating devices outside gc can work correctly, in all cases, with Postscript | 15:44.47 |
| HenryStiles | chrisl: well if you search for PSI_INCLUDED in "psi" there are lots of places where we sidestepped problems. The change in zsetdevice is perhaps the most important. | 15:52.51 |
| chrisl | HenryStiles: I'd define that as breaking Postscript..... | 15:54.09 |
| Robin_Watts | tor8: Apologies, I didn't see your message. | 15:56.57 |
| | (I blame Scott for making my facebook beep every couple of seconds) | 15:57.11 |
| HenryStiles | chrisl: are there other issues you have with sharing a device other than that? | 15:59.04 |
| Robin_Watts | tor8: Where do you think the rect is not used? | 15:59.15 |
| | fz_clip_text ? | 16:00.05 |
| chrisl | HenryStiles: Just the interaction with Postscript - even without the gc problem, I think it's going to be problematic that Postscript can select a new device "under the feet" of the language switching front end | 16:00.19 |
| tor8 | Robin_Watts: it's always computed from the object being passed, so it's a cached value in essence | 16:00.41 |
| | for fz_clip_image_mask it's always the unit rect transformed by the ctm | 16:01.02 |
| | for paths it's always the fz_bound_path rect transformed by the ctm | 16:01.14 |
| | etc | 16:01.25 |
| Robin_Watts | No. For paths, it's *either* what is passed in, or it's calculated. | 16:01.43 |
| | If a value is passed in, we use that, if not we recalculate. | 16:02.08 |
| | IMHO we should do that on all the functions. | 16:02.26 |
| | of course, that may be hard :) | 16:02.32 |
| tor8 | Robin_Watts: I looked at all the call sites; and where we have calculated it it's always the same as we calculate when nothing is passed in | 16:03.08 |
| | though there are a few cases where we don't calculate if it's null | 16:03.29 |
| Robin_Watts | tor8: OK, so that's the case now, but we could have other people calling this. | 16:03.39 |
| tor8 | I'm uncomfortable with having this argument -- it's an optimization so we don't need to recompute the bounding boxes | 16:04.09 |
| Robin_Watts | Is exposing the rect purely a performance thing? | 16:04.16 |
| chrisl | HenryStiles: So, we might be able to deal with the gc problems by changing how the PS interpreter handles device objects (refs), so they actually use reference counting for the device memory. And we might be able to deal with Postscript's ability to change the device by encapsulating each PS job in an extra save/restore layer. | 16:04.16 |
| tor8 | it's purely performance related. passi n the wrong thing and you'll get slow performance or wrong results | 16:04.33 |
| Robin_Watts | So the rect is not honoured on playback? | 16:04.58 |
| | I'm thinking, for instance, of doing an fz_clip_path, and passing in a big path, but a smaller rectangle. | 16:05.29 |
| | My hopes would be that the clip would be the path clipped to the rectangle. | 16:05.49 |
| | If that's what we do, then dropping the rect from the API leaves us with a less capable API. | 16:06.18 |
| tor8 | it's not designed as a separate scissor rectangle | 16:06.33 |
| Robin_Watts | If that's not what we do, then it's false advertising, and we should fix it, or change the API. | 16:06.37 |
| tor8 | it may behave like one now, but that's purely accidental | 16:06.43 |
| | to save us recomputing the bounds of a text or path when deciding how big the temporary buffers need to be in the draw device | 16:07.14 |
| | unless you've gone and added something else to it; it's been a while since I poked at this code | 16:07.55 |
| Robin_Watts | tor8: I understood that it was supposed to be a separate scissor rectangle. | 16:08.26 |
| | and the display list device stores the rectangle, and transforms it on playback before passing it through. | 16:08.46 |
| | So it saves a lot of repeated bound calculations. | 16:08.55 |
| tor8 | it's supposed to be the cached bound calculation, nothing else | 16:09.10 |
| | so we can use it as a scissor, but that is not its purpose | 16:09.19 |
| | that would completely break the device interface assumptions | 16:09.29 |
| Robin_Watts | OK, so what would you like to do here? | 16:09.48 |
| tor8 | I can't imagine we'd add clip rectangles based on this to the pdf_device, for instance? | 16:09.51 |
| | I can think of two things -- remove it altogether and always recompute. that might be slow for paths, but we do it for text objects already. | 16:10.25 |
| | or make sure it can always be null, and don't expose it to java | 16:10.48 |
| Robin_Watts | Minimum thing would be to add a comment to the device interface to specify that if used, it must be the bounds of the path. | 16:11.09 |
| | I'd be in favour of the latter, I think. | 16:11.17 |
| tor8 | I would still remove it from the clip_image_mask call (that's a simple transform of the unit rect) | 16:12.03 |
| | but yes, I think the latter will be better | 16:12.16 |
| | and we can make sure that all calls to fz_clip_xxx can take null | 16:12.55 |
| HenryStiles | chrisl: that leads me to believe we or I should try and patch up the old language switch stuff and go from there. I think it can be made a bit more sane. | 16:13.09 |
| tor8 | we could also ensure that all device->clip_xxx callbacks take the computed bounds, but that may be wasted if they don't need it | 16:13.18 |
| Robin_Watts | tor8: OK. The displaylist will need updating then for the clip_image_mask call. | 16:13.28 |
| tor8 | so the question is whether to handle null at the fz_clip or inside the devices | 16:13.36 |
| Robin_Watts | In the fz_clip, controlled by a device hint? | 16:14.30 |
| | DEVICE_HONOURS_CLIPS or something. | 16:14.56 |
| chrisl | HenryStiles: We'd have to establish a good way to know when a PS job is starting, and when it's complete. | 16:15.05 |
| Robin_Watts | DEVICE_IGNORES_CLIPS maybe. | 16:15.11 |
| | so the text device can set that, and we can avoid doing the calculation in that case. | 16:15.21 |
| | tor8: Oh, actually... we can avoid doing the calculation in the case that the dev->clip_stroke_path (or whatever) is NULL. | 16:16.22 |
| | tor8: Cluster checks just came back clean on my stuff (as you'd expect) | 16:26.15 |
| HenryStiles | chrisl: I'm going to build the ls stuff and see what all is broken and think about it some more. | 16:27.10 |
| tor8 | Robin_Watts: the flaw in printing objects, I believe that's a bug in gs. it depends on the value of do_tight, but a / is always a new token | 16:29.47 |
| Robin_Watts | tor8: So how do we proceed on this? Are you going to keep working, or do you want me to review what's there? | 16:29.54 |
| | /Fredendobj | 16:30.05 |
| tor8 | oh! | 16:30.15 |
| | I misread. | 16:30.21 |
| | that bug would be there for 'true' and 'false' and literal numbers too or is it just names? | 16:31.15 |
| chrisl | HenryStiles: If you think that's best. Of course, hacking up the original language switch doesn't get us the consistent front end API we really wanted, nor does it get rid of the pl_universe stuff | 16:31.20 |
| tor8 | trueendobj, 42endobj | 16:31.23 |
| Robin_Watts | tor8: I only saw it for Names, but the others are probably there too. | 16:31.40 |
| | And the fix should address all of them. | 16:31.56 |
| tor8 | Robin_Watts: all lgtm. there's a couple of commits on tor/master waiting to go as well. | 16:32.53 |
| | I've spotted some problems with sebras/master that I'm still waiting to hear back from sebras on | 16:33.14 |
| Robin_Watts | tro8: looking now. | 16:33.18 |
| | tor8: I have no strong objections to any of those. lgtm. | 16:35.37 |
| | Do you want to push, and I'll rebase and push? | 16:35.49 |
| tor8 | Robin_Watts: I'd prefer if I pushed; I've got the jni and script branches hanging off tor/master | 16:36.13 |
| Robin_Watts | is confused... | 16:36.37 |
| tor8 | meaning, that I prefer if I pushed tor/master to origin and not have to rebase half a dozen branches :) | 16:37.02 |
| | Robin_Watts: go ahead and rebase, I've pushed. thanks for looking. | 16:37.18 |
| | Robin_Watts: okay, tor/script now has an example of a javascript creating a draw device and drawing some paths and text to it and saving the pixmap as a png | 16:38.39 |
| HenryStiles | chrisl: I do intend to get rid of much of the bloat that has accumulated in pl_universe and I think doing this (fixing up the current ls) incrementally will make the languages much easier to plugin elsewhere. | 16:39.28 |
| Robin_Watts | Ok, pushed. | 16:39.42 |
| tor8 | Robin_Watts: and my ramblings are obviously insane... I think I should stop writing code now... | 16:40.02 |
| chrisl | HenryStiles: Fair enough. | 16:40.42 |
| Robin_Watts | tor8: What does mujs use as an allocator ? | 16:41.24 |
| | Does it just call malloc/free, or is there some way to set custom allocators for it? | 16:41.56 |
| tor8 | Robin_Watts: there is a way to set custom allocators | 16:42.03 |
| | but I've not set them for mutool run | 16:42.11 |
| Robin_Watts | right. It might be nice if you did. | 16:42.22 |
| tor8 | they're the first and second arguments to js_newstate | 16:42.22 |
| Robin_Watts | a) because it would be an example. | 16:42.28 |
| tor8 | Robin_Watts: it would. it slipped my mind. | 16:42.33 |
| Robin_Watts | b) because everything in mutool uses fz_malloc etc. | 16:42.38 |
| tor8 | Robin_Watts: commit on tor/master that uses the allocator | 16:44.46 |
| Robin_Watts | The first commit is certainly fine. | 16:46.30 |
| | The second one, my eyes glaze over a bit after a while, but it looks plausible. | 16:46.44 |
| tor8 | Robin_Watts: if you're itching for a new mupdf project ... I'm thinking of writing a fz_show_string function that takes an utf-8 string and shapes it with bidi, harfbuzz and fallback fonts into a fz_text | 16:47.03 |
| | Robin_Watts: yeah, it's a big blob of code | 16:47.19 |
| Robin_Watts | The third one says "WIP" in the commit message, but... WOW. To have that ability from the previous commit is REALLY cool. | 16:47.27 |
| | And the allocator one looks good too. | 16:47.42 |
| | I have a list of stuff on a post it note in front of me of stuff I want to do before the meeting. | 16:48.38 |
| | but, yes, I could potentially be interested in that. | 16:49.07 |
| | The idea, I assume, being to have a function that does some of the stuff that the epub agent does, but in a way that can be easily reused? | 16:49.52 |
| mvrhel_laptop | gosh I guess the meeting is coming up quick here | 16:50.14 |
| tor8 | yeah. something to expose to say svg and gui viewers and the annotation ap stream creation, etc. | 16:50.31 |
| | I would imagine it be a simple single-line kind of thing; maybe a second function that does wrapping as well | 16:51.24 |
| Robin_Watts | tor8: Will ponder on it. | 16:52.17 |
| | That might be a good thing for the flight. | 16:52.34 |
| tor8 | Robin_Watts: thanks. time to head out for a bit, grocery shopping and dinner. | 16:52.43 |
| | Robin_Watts: yeah, it could be a good flight sized project. | 16:53.01 |
| | Robin_Watts: we could maintain the path bounds as the path is created, and not have to worry about the costs of recomputing the bbox | 17:41.15 |
| | Robin_Watts: huh, so fz_pack_path clones the path while packing it? | 18:07.21 |
| | I was wondering why append_display_node didn't fz_keep the path | 18:07.45 |
| Robin_Watts | fz_pack_path doesn't clone the path. | 18:23.28 |
| | You call fz_pack_path with a pointer to somewhere to pack the path into. | 18:25.27 |
| | so, yes I guess that is a form of cloning. | 18:26.13 |
| tor8 | Robin_Watts: it clones into the display list buffer, right? | 18:32.48 |
| Robin_Watts | yes. | 18:32.55 |
| tor8 | so, pdf text rendering mode fill+stroke will get two copies of the same path data in the display list | 18:33.03 |
| | since we call first fill, then stroke, with the same fz_path object | 18:33.15 |
| Robin_Watts | tor8: Unless I've been clever enough to spot repeated paths, yes. | 18:33.37 |
| tor8 | Robin_Watts: I don't understand the reasoning behind 'image2 = fz_keep_image(ctx, image)' | 18:36.18 |
| | in the display list | 18:36.23 |
| | Robin_Watts: in the path packing, the fz_throw("Can't pack a path that small!") looks like it's in the wrong branch | 18:59.20 |
| | oh wait, no, I'm just confused. | 19:00.07 |
| Robin_Watts | tor8: Let me look at the image2 thing. | 19:02.01 |
| tor8 | Robin_Watts: I have a tentative fix for removing the fz_rect to the clip functions. | 19:02.42 |
| | turns out, the draw device doesn't even use it | 19:02.52 |
| Robin_Watts | tor8: We get passed an image, whose reference we can use for the duration of the call. | 19:03.08 |
| | We need to keep a reference ourselves, so we clone it. | 19:03.16 |
| | s/clone/keep/ it. | 19:03.23 |
| tor8 | why the second variable? | 19:03.38 |
| Robin_Watts | why not? | 19:04.03 |
| tor8 | also, shouldn't the keep be done inside append_display_node (like where the paths are packed) | 19:04.06 |
| | because it's confusing :) | 19:04.27 |
| Robin_Watts | tor8: It can't be done inside append_display_node because the private_data is a void *. | 19:04.38 |
| | i.e. append_display_node doesn't know what it's taking. It just takes a pointer to "something" and the size. | 19:05.01 |
| tor8 | ah, right! | 19:05.11 |
| Robin_Watts | In this case the "something" it takes a pointer to is image2. | 19:05.13 |
| | So that's why the second variable ) | 19:05.21 |
| | :) | 19:05.23 |
| tor8 | and it's taking the stack address of the local variable...!? | 19:05.38 |
| | oh, so it can copy the address | 19:05.48 |
| | okay, I get it. | 19:05.50 |
| | you could just take the & of the function argument though | 19:06.05 |
| Robin_Watts | You trust compilers more than me :) | 19:06.22 |
| tor8 | only the non-optimizing kind.... :) | 19:06.41 |
| | Robin_Watts: if you could take a look at tor/master and see if I've cocked up the display list code I'd be grateful | 19:07.15 |
| Robin_Watts | tor8: will do, but not immediately - being called away, sorry. | 19:07.28 |
| tor8 | I'm not sure exactly what is going on with all of the rects being passed and which ones are required and not | 19:07.33 |
| | I suspect you do this so that you can minimize the rects for begin_mask, begin_group and begin_tile | 19:08.02 |
| Robin_Watts | tor8: In the display device? | 19:25.59 |
| tor8 | in the display list device | 19:26.19 |
| | the stack of rects and rect_for_update, etc | 19:26.30 |
| Robin_Watts | I can't remember offhand. It'd be guesswork at best without me having a stare at the code for a bit. | 19:27.28 |
| tor8 | the commit came back clean from clusterpush at least :) | 19:27.49 |
| Robin_Watts | tor8: Was there a noricable change in reported speed? | 19:29.06 |
| | 11 minutes slower (1hr26 being the baseline) | 19:29.48 |
| | I'd be tempted to rerun to see if that varies much. | 19:29.58 |
| tor8 | Robin_Watts: yeah. | 19:30.35 |
| | I'll fire off one more clusterpush | 19:31.03 |
| Robin_Watts | Ah, right. All the container stack stuff that is relied upon by things like the display device is in the device wrappers. | 19:31.37 |
| | I was thinking that we could call the device functions directly to supply the rects, but we can't... | 19:32.09 |
| tor8 | it *looks* to me like we have two layers of rectangle tracking | 19:32.41 |
| Robin_Watts | When playing back from displaylist we used to avoid ever having to bound paths. Now we have to bound every path. | 19:32.46 |
| tor8 | one in the fz_device, and one in the list-device | 19:32.50 |
| Robin_Watts | tor8: The one in the fz_device was extracted from the draw device. | 19:33.16 |
| tor8 | the draw device doesn't call fz_bound_path | 19:33.43 |
| | and it doesn't use the fz_rect it gets passed | 19:33.53 |
| | it does its bounding on the flattened edge list | 19:34.05 |
| Robin_Watts | tor8: Right, so the rects are purely for deciding container sizes (like masks etc). | 19:34.38 |
| tor8 | also, fz_bound_path should now be very fast (it just transforms the saved bbox with the ctm) | 19:34.44 |
| Robin_Watts | Paths now have a saved bbox as part of them? | 19:35.10 |
| | The display list device doesn't keep a stack of rects. | 19:35.30 |
| tor8 | Yes. That's the commit just before. | 19:35.42 |
| | fz_list_device->stack | 19:35.58 |
| | what's that then? | 19:36.04 |
| | the display list doesn't keep a stack, but the device sure does | 19:36.21 |
| Robin_Watts | Right. The display list *writer* keeps a stack. | 19:37.23 |
| tor8 | Robin_Watts: that last clusterpush was 4 minutes faster than the one before it | 19:37.42 |
| Robin_Watts | so only 7 minutes slower than before? | 19:37.59 |
| tor8 | yes. and that's with the exact same sha1 | 19:38.13 |
| | so I suspect this is within the usual fluctuations of the cluster | 19:38.31 |
| Robin_Watts | Yes. | 19:38.37 |
| | Well, it's not stupidly larger than the usual fluctuations of the cluster at least. | 19:39.00 |
| | Having a bbox for the path irks me a bit. | 19:40.24 |
| | I feel like we ought to be able to make better use of that in the common axis aligned rectangular path case. | 19:40.49 |
| | There probably isn't much point in storing the rect in the list in the FZ_CMD_CLIP_PATH case any more. | 19:43.19 |
| | likewise the clip_stroke_path case. | 19:43.37 |
| tor8 | I think we might want them to update the areas for begin_mask etc | 19:44.06 |
| Robin_Watts | and the fz_list_clip_image_mask case. | 19:44.11 |
| tor8 | but we may not need to store them in the actual nodes though | 19:44.15 |
| Robin_Watts | tor8: Yeah, we can just move the calculation from the storing to the reading. | 19:44.29 |
| | otherwise we end up packing the same bbox into the list twice - once as part of the path, once as part of the node data. | 19:45.22 |
| tor8 | Robin_Watts: I think we should only store the rects for the mask/group/tile nodes; but those we recompute as we create the display list | 19:46.30 |
| Robin_Watts | tor8: I think we *should*, yes. | 19:47.01 |
| | But in your latest patch we still store for the fz_clip_ cases too. | 19:47.20 |
| tor8 | what we currently do, I'm a bit intimidated by the intricacies of the display list writer | 19:47.33 |
| Robin_Watts | just pass NULL instead of &rect :) | 19:47.46 |
| tor8 | well, if we don't update the rects for masks, tiles and groups ... there's no need for the stack in the writer at all? | 19:48.20 |
| Robin_Watts | tor8: eh? | 19:48.43 |
| tor8 | but we do, so we still need to pass the fz_rect | 19:48.52 |
| | passing NULL would mean we don't update the writer->stack[top].update rect properly | 19:49.15 |
| | in fz_append_display_node | 19:49.44 |
| Robin_Watts | oh! So it would. | 19:49.46 |
| tor8 | but we could make sure to only save the rect for mask/group/tile | 19:50.15 |
| Robin_Watts | Right, so what is happening there is EXACTLY me minimising the rects used for clips etc. | 19:50.33 |
| | And the sole point of that is so that we can pass in a smaller box than we might expect as the scissor. | 19:51.11 |
| | If we are never allowing ourselves to do that, then there is no point in having the first 3 cases in fz_append_display_node | 19:51.55 |
| | What currently happens, i think is that we store the empty rect in the node data, and keep a pointer to it. | 19:52.59 |
| tor8 | okay. so if I understand correctly, the display list would make the bounding box rect (formerly) passed to dev->clip_path smaller than the path | 19:53.17 |
| Robin_Watts | As we put more and more stuff into the list that rect is grown. | 19:53.17 |
| tor8 | based on what's inside the clip area | 19:53.22 |
| Robin_Watts | When we pop the clip we then intersect that with the path bbox, so that the rect stored in the data at the end us the minimally sized one. | 19:53.52 |
| tor8 | so that we can make an even smaller clip buffer than usual | 19:54.02 |
| Robin_Watts | Yes. | 19:54.11 |
| tor8 | and that gets us a bit of extra performance in case the display list is used | 19:54.15 |
| | for these cases | 19:54.21 |
| Robin_Watts | So, it is a shame to lose this. | 19:54.22 |
| tor8 | Robin_Watts: yes. we could make the writer->update poke at the packed path bounds though :) | 19:54.44 |
| Robin_Watts | Especially for stupid (but common) PDF files that "set the clip to the size of the page", "output text", "pop clip" | 19:54.50 |
| tor8 | Robin_Watts: well, we handle those cases by scissoring anyway | 19:55.03 |
| Robin_Watts | tor8: Urgh :( | 19:55.05 |
| | the path bounds should always be consistent with the path. | 19:55.22 |
| tor8 | any rectangular clip path is treated as a scissor in the draw device | 19:55.32 |
| Robin_Watts | being called for food. | 19:55.37 |
| tor8 | Robin_Watts: okay, ignore those two commits. | 20:15.05 |
| | I'll make a new one where I move the rect to the end of the argument list and call it transformed_scissor_hint | 20:15.14 |
| | but for symmetry we should also add it to clip_text | 20:17.08 |
| Robin_Watts | tor8: That sounds great. | 20:32.46 |
| sebras | tor8: back. | 20:47.22 |
| | tor8: I'm attempting to reproduce the problem where you see multiple spaces inbetween <p> tags. | 20:59.40 |
| | tor8: oh.. <p>hello</p><p>world</p> worked fine, and having \n before/after didn't matter, but doing <p>hello</p>\n<p>world</p> certainly looks peculiar. | 21:03.33 |
| | tor8: I think I know what is happening, it is the linebreaks that are transformed into spaces as they are now following a non-space characters ( | 21:04.43 |
| | 'o' and 'd' respectively in this example) | 21:04.52 |
| tor8 | Robin_Watts: updated commit on tor/master, running a clusterpush now as well | 21:32.00 |
| | sebras: yeah, I think that newline between the two <p> tags is the problem | 21:33.27 |
| | since it creates a new anonymous block box for the space | 21:33.37 |
| sebras | tor8: maybe we should set skip_white == 1 inbetween blocks? | 21:36.22 |
| | tor8: that way the space would disappear. | 21:36.48 |
| tor8 | sebras: I thought you did that already? | 21:37.18 |
| | I'm too brain fried to think about this tonight, have been digging too deep in the display list device. | 21:37.32 |
| sebras | tor8: I'm currently playing with setting *skip_white = 1; before the second call to generate_text() in generate_boxes(), but I'm not yet sure if this is a good approach. | 21:37.43 |
| | tor8: I must understand this box-model thing better to be convinced. but I'll play around with this until I have something I believe in. | 21:38.21 |
| tor8 | sebras: basically, at every place we would create a new BOX_FLOW, skip_white should be true | 21:38.52 |
| | because at the beginning of each BOX_FLOW we do the while loop to skip initial white space | 21:39.09 |
| sebras | right. | 21:39.39 |
| | tor8: mm, something like that, I'm just trying to locate where in the code this happens. | 21:43.42 |
| | tor8: ok. so I think I found where that pesky *skip_white = 1 ought to go. new patch over at sebras/master. | 23:00.28 |
| | tor8: please don't find any more issues with it. :) | 23:00.41 |
| | Forward 1 day (to 2016/02/23)>>> | |
IRC Logs