| | <<<Back 1 day (to 2013/08/21) | 2013/08/22 |
| atulagrwl | quit | 08:08.14 |
| chrisl | holds breath for deluge of 9.09 problems...... | 10:03.13 |
| kens | :-( | 10:04.32 |
| Robin_Watts | well done chrisl. | 10:12.17 |
| chrisl | Robin_Watts: thanks - I wish I could say I survived with my sanity intact...... | 10:13.04 |
| kens | has all digits crossed | 10:13.06 |
| chrisl | I'm half tempted to log off for the rest of the day...... | 10:13.38 |
| kens | Good plan ! | 10:13.48 |
| Robin_Watts | waits for Sags to arrive... :) | 10:14.12 |
| chrisl | I really would go back to bed, and pull the covers over my head, then! | 10:15.45 |
| kens | I'msurprised he hasn't complained about my last comment on filenameforall | 10:16.18 |
| chrisl | "It's good enough, get lost"? | 10:16.43 |
| kens | Yep :-) | 10:16.55 |
| chrisl | Well, I think it's unreasonable to expect filenameforall to be a usable replacement for a proper regexp search | 10:18.22 |
| paulgardiner | Robin_Watts: updated commit on paul/master. Can you just give it one more quick check over? | 10:18.55 |
| Robin_Watts | ok | 10:19.03 |
| kens | chrisl I agree. While he's correct it would mean that path separators would have to be written (c:\\\\*) | 10:19.03 |
| chrisl | kens: I wonder why Adobe didn't specify that "/" be used for all paths in PS - most other things they followed a Unix-like model for | 10:20.28 |
| kens | I really wish they had :-( | 10:20.44 |
| Robin_Watts | paulgardiner: OK. | 10:20.57 |
| paulgardiner | Great. Thanks. I'll just give it one more test on my phone and push it to golden | 10:21.37 |
| Robin_Watts | paulgardiner: I've just rebased it here prior to pushing. | 10:21.53 |
| | when you're happy, tell me and I'll push it. | 10:22.02 |
| paulgardiner | Thanks | 10:22.10 |
| chrisl | Now, I wonder what the heck I was doing when this fiasco started.... | 10:22.28 |
| Robin_Watts | chrisl: Working for global ? | 10:22.41 |
| | oh, wait, I see, sorry.... | 10:22.47 |
| | :) | 10:23.01 |
| chrisl | Robin_Watts: that was a very different (and even worse) fiasco....... | 10:23.12 |
| paulgardiner | :-) | 10:23.13 |
| tor7 | paulgardiner: Robin_Watts: we might want a flag to pdfclean to create this type of xref (but only if you actually compress the xref streams, and use the predictor, to make them small) | 10:23.29 |
| paulgardiner | tor7: yes that would be worth doing | 10:23.56 |
| Robin_Watts | tor7: sebras: Just looking at sebras fixes now. | 10:25.12 |
| | "Cancel page timeout when searching in x11 viewer." | 10:25.32 |
| | The code looks plausible, but some comments in the commit message as to why this is required would be nice. | 10:25.53 |
| paulgardiner | Robin_Watts: Ok. That's good to push | 10:27.59 |
| Robin_Watts | pushed | 10:37.10 |
| atulagrwl | thanks a lot paulgardiner for quick fixing this issue :) | 10:38.06 |
| Robin_Watts | tor7:sebras: "Set page number timeout outside of x11 main" - again, why? | 10:38.24 |
| paulgardiner | atulagrwl: No problem. Thanks for reporting it. It was an important issue to fix. | 10:38.50 |
| Robin_Watts | tor7:sebras: All the commits look good, apart from me not really understanding the 2 I've mentioned. Some slightly more verbose commit messages would be nice. | 10:40.56 |
| tkamppeter | chrisl, thanks for the quick release of GS 9.09, I have uploaded it to Ubuntu Saucy now. | 10:45.34 |
| | chrisl, what was the show stopper of 9.08? | 10:45.56 |
| Robin_Watts | tkamppeter: Turns out that gsview accesses internal parts of gs. And kens fixed a bug in gs that involved changing those internal parts, and that made gsview fail. | 10:49.00 |
| | So kens has had to rework the fix to keep gsview happy. | 10:49.09 |
| | Oh, wow. Upping the font cache size makes a massive difference to mupdf timings at 1200dpi. | 10:50.09 |
| | Twice as fast for the PLRM. | 10:50.21 |
| tkamppeter | Robin_Watts, thanks. | 10:51.35 |
| | Robin_Watts, does the font cache size increase also make Ghostscript faster when printing under Linux? | 10:52.11 |
| Robin_Watts | tkamppeter: The font cache size increase I just referred to was a mupdf thing, not a gs thing. | 10:52.48 |
| | I'm not sure how the font cache size is configured in gs. | 10:53.11 |
| | kens, chrisl: Can you remember how band sizes are calculated in gs in the presence of transparency? | 10:54.06 |
| kens | Never knew that | 10:54.17 |
| Robin_Watts | ISTR that there is some logic like "if we use transparency, divide the bandheight by F" where F is some special fudge factor. | 10:54.51 |
| tor7 | Robin_Watts: ah. I thought about adding a warning message for when we exceed the font cache limits. | 10:56.37 |
| chrisl | Robin_Watts: I think that's about right (re band sizes) - the usual GS "magic" :-( | 10:57.09 |
| Robin_Watts | tor7: At the moment, when we fill the font cache, we bin the whole damn lot and restart. | 10:57.17 |
| tor7 | Robin_Watts: yeah. we could probably rewrite the cache to be smarter all around. | 10:57.55 |
| | the current design stems from back when I tried to have it all the glyph bitmaps in one contiguous chunk of memory. | 10:58.18 |
| | which made the LRU eviction very expensive | 10:58.33 |
| chrisl | tkamppeter: just as Robin_Watts said. The problem was to do with global/local VM modes during startup - pretty obscure and knarly stuff :-( | 10:58.35 |
| Robin_Watts | chrisl: I am tempted to copy that magic for mupdf :) | 10:59.00 |
| tor7 | for the opengl stuff I've got another issue ... I really can't evict stuff that I've uploaded into a texture for fear of causing pipeline stalls | 10:59.23 |
| Robin_Watts | Is there any way we can know when a texture is done with? | 11:00.07 |
| | i.e. could we have a queue (or ring) of textures and use them in turn? | 11:00.20 |
| chrisl | Robin_Watts: I suspect the problem there is that the "magic" was arrived at by testing and guess work based on the GS's implementation - you could use the same "magic" but you'd probably different numbers | 11:00.34 |
| | tkamppeter: and, BTW, thanks for being understanding about the 9.08 confusion | 11:01.14 |
| | Robin_Watts: does mupdf accumulate a transparency group into a display list before rendering it? | 11:02.19 |
| Robin_Watts | chrisl: Not necessarily. | 11:02.36 |
| | With MuPDF we say "run this page to this device". | 11:02.52 |
| tor7 | Robin_Watts: well, you can discard the entire texture and make a new one, and it'll get freed once the rendering with it is done | 11:03.03 |
| Robin_Watts | and the pdf interpreter runs on the page contents. | 11:03.12 |
| tor7 | so we could bin the whole texture and start from scratch with a new one | 11:03.32 |
| Robin_Watts | The device is then either a renderer or a display list writer (or a text extractor or...) | 11:03.34 |
| | tor7: but presumably the act of making a new texture is costly ? | 11:04.01 |
| chrisl | Robin_Watts: I just wondered if you could do blending in bands, separately from page bands - that would have allowed greater flexibility | 11:04.10 |
| tor7 | Robin_Watts: possibly. I think if you just say "make me some new storage for this existing texture" that call is fairly cheap | 11:04.43 |
| | compared to setting up a whole new texture object | 11:04.49 |
| Robin_Watts | chrisl: The problem is that the top level app allocates a band for the pixmap to draw into. | 11:05.07 |
| tor7 | for vertex buffers, reallocating it some new storage is the recommended way to feed dynamic data | 11:05.28 |
| Robin_Watts | If it then ends up needing transparency, we've already spent all our bytes on the top level pixmap. | 11:05.40 |
| tor7 | I'm assuming the same ought to be true for textures as well | 11:05.51 |
| Robin_Watts | We can detect the need for transparency at the top level, and so choose to restrict our bandsize further. | 11:06.12 |
| tor7 | but first I need to get to the bottom of these matrixes and why things aren't transforming as they should :( | 11:06.17 |
| chrisl | Robin_Watts: so what happens with a frame device? | 11:06.20 |
| Robin_Watts | We have no real concept of frame or band devices. | 11:06.44 |
| | We just say "render to this pixmap". | 11:06.51 |
| | and if the pixmap happens to be a band shaped thing, great. | 11:07.06 |
| | tor7: yeah, get it working, then we'll worry about making it fast :) | 11:07.37 |
| chrisl | I must look at the mupdf code in more detail at some point! | 11:07.39 |
| Robin_Watts | chrisl: When you do, you'll go... "oh, is that all..." | 11:08.05 |
| chrisl | After I get past the confusing formatting..... | 11:08.25 |
| Robin_Watts | It's like a magic trick. Horribly mundane when you know how it's done. | 11:08.25 |
| | and the absence of confusing macros. | 11:08.46 |
| | So, I have a profile here from MuPDF on J12 at 1200 dpi. | 11:09.17 |
| | Top entries: | 11:09.19 |
| | 4998 17.7% 17.7% 4998 17.7% fz_copy_ft_bitmap | 11:09.34 |
| | 3334 11.8% 29.4% 3334 11.8% fz_paint_affine_near | 11:09.36 |
| | 2455 8.7% 38.1% 2455 8.7% Bezier_Up | 11:09.38 |
| | 1966 6.9% 45.1% 1966 6.9% fz_paint_solid_color | 11:09.39 |
| | 1630 5.8% 50.8% 1630 5.8% Split_Conic | 11:09.41 |
| | 1418 5.0% 55.8% 1418 5.0% fz_paint_span | 11:09.42 |
| | 1257 4.4% 60.3% 1257 4.4% Render_Single_Pass | 11:09.44 |
| | 1233 4.4% 64.6% 1233 4.4% memset | 11:09.45 |
| | So why can't I find any sign of a function called "Bezier_Up" in our code? :) | 11:09.56 |
| | I'm guessing that's a freetype thing. | 11:10.11 |
| | chrisl, tor7: Either of you recognise Bezier_Up ? | 11:15.09 |
| kens | That and Sro ftraster.c | 11:15.49 |
| | Robin_Watts : ftraster.c | 11:16.00 |
| Robin_Watts | kens: Thanks, my grep just found that too. Why didn't my VS search find that? | 11:16.18 |
| kens | I don't know | 11:16.25 |
| | maybe we don't make a .sbr ? | 11:16.49 |
| Robin_Watts | kens: we do | 11:17.38 |
| | I suspect it's to do with the fact that freetype does #include "ftraster.c" and stuff like that. | 11:17.55 |
| kens | Well I've seen some oddities with the .sbr results | 11:17.57 |
| | Robin_Watts : yes, some of GS confusesw it similarly | 11:18.10 |
| kens | lunches | 11:18.38 |
| tor7 | Robin_Watts: looks like font rendering is big there... Bezier_Up and Split_Conic look like freetype to me. | 11:19.22 |
| | I'm surprised fz_copy_ft_bitmap is up there that high... are you running -b0 or contone? | 11:19.58 |
| | the non-AA case turns on hinting and off antialiasing for freetype as well, making the bitmap extraction from freetype read bits and write bytes | 11:20.26 |
| Robin_Watts | This is b0. | 11:28.51 |
| | At picsel we cached chars as 'clipmasks'. | 11:29.43 |
| | rather than having lines as runs of mask values, we had them as run length encoded things. | 11:30.18 |
| | off pixels, edge pixels, on pixels. | 11:30.38 |
| | Plotting those out is much faster, and they take much less room. | 11:31.07 |
| tor7 | SWAR/SIMD plotting of full bitmaps is probably faster still | 11:32.40 |
| | one thing we could do is make sure the glyph pixmap strides sit on nice alignments | 11:33.18 |
| Robin_Watts | tor7: Not when you have to allow for filling the masks with different colors. | 11:33.18 |
| | The bitmaps we cache are 'masks', and they need to be filled with color; in mupdfs case, always a flat color I think (but in picsels case we coped with filling with bitmaps etc too) | 11:34.29 |
| tor7 | plotting RLE coded masks that straddle the left/right scissor edges needs a bit more care | 11:34.44 |
| | but if you think it's worth pursuing, be my guest :) but please only in the draw device when filling the glyph cache | 11:35.09 |
| | I still need full pixmaps out from the fz_render_xxx_glyph | 11:35.19 |
| Robin_Watts | In a typical bitmap, as the dpi goes up, most pixels are either off or on, the number of 'edge' pixels that require blending etc are quite small. | 11:35.23 |
| tor7 | Robin_Watts: yeah. for 100dpi-ish displays, most pixels are blended or off | 11:36.09 |
| | 1200dpi, you have a point, run length coded might speed things quite up a bit. | 11:36.41 |
| | eh, pardon the mangled word order there | 11:36.55 |
| Robin_Watts | Even at 100dpi, there are noticable benefits to be had with rle. | 11:37.08 |
| | I've never pursued this before, partly because my head is so full of exactly how I did it at Picsel. | 11:37.40 |
| | I don't think their patents cover this (in fact, while I was there, and they sold the patents on, they had me rework the plotters to avoid the patents) | 11:38.27 |
| | Even with a glyph cache of 4Meg, we end up binning the cache multiple times per page at 1200dpi with J12. | 11:46.06 |
| tor7 | Robin_Watts: there's nothing preventing us from having an "unlimited" cache currently | 11:48.49 |
| | but an LRU scheme would probably be best | 11:49.12 |
| Robin_Watts | tor7: yeah. | 11:49.18 |
| | the problem is the hash table. | 11:49.21 |
| tor7 | a double-linked list of glyph entries should do the trick | 11:49.22 |
| | but then there's the problem of deleting from the hash table | 11:49.36 |
| Robin_Watts | yeah. | 11:50.06 |
| | Unless we change to a different hash table (one without linear probing) | 11:50.25 |
| | buckets would work nicely. | 11:50.57 |
| | bucket chains, I mean. | 11:51.18 |
| tor7 | how bad would a binary tree be in comparison? | 11:51.42 |
| | to a hash table | 11:51.44 |
| Robin_Watts | Slower lookup. | 11:51.59 |
| tor7 | might pay off if discarding is cheaper | 11:52.29 |
| Robin_Watts | hash table + LRU + linear chains for buckets would hit all the bases, and be simple I think. | 11:52.49 |
| tor7 | not sure if it's going to be significantly slower, in the face of hash table collisions | 11:52.52 |
| | but yes, that ought to be simple enough and work quite a bit better than our current toss-it-all approach | 11:53.44 |
| Robin_Watts | I will play with that. | 11:53.58 |
| pipitas | Hi â I have a bug report to submit which goes with some files containing sensitive customer data. Is it OK for me to attach a password protected *.7z file to the report, then ask one of you here to move it into the non-public space of your bugzilla, and then tell you the password here in IRC? | 12:18.11 |
| Robin_Watts | pipitas. Sure. Go for it. | 12:18.46 |
| | but .7z. Really? | 12:19.04 |
| pipitas | Robin_Watts: Ok, I just don't know how to put a password on .zip or .tar.gz on commandline. But I'll manage to use .zip or .tar.gz too :) | 12:20.56 |
| Robin_Watts | .zip has passwords and it's a lot more standard a tool. | 12:21.18 |
| pipitas | I've to prepare a few file, then I'll tell you when it's done | 12:21.31 |
| Robin_Watts | Or, if you'd rather, open the bug, and mail me the .zip without a password, and I'll attach it. | 12:21.53 |
| pipitas | 7z can possibly also create .zip, I'll check... | 12:22.08 |
| Robin_Watts | it can, I believe. | 12:22.17 |
| | tor7: Did you see the bug from Christophe? I was mumbling here about it last night. | 12:22.47 |
| tor7 | Robin_Watts: ligature one? | 12:23.09 |
| pipitas | Robin_Watts: is it robin DOT familyname AT artifex DOT com ? | 12:23.09 |
| Robin_Watts | tor7: yeah. | 12:23.15 |
| | it is. | 12:23.17 |
| | pipitas: it is. | 12:23.24 |
| | I think it's back to our font fallback being less than perfect. | 12:23.43 |
| tor7 | I think all our fonts should have the 'fi' ligature as a minimum, it might be something else going on | 12:24.28 |
| | okay, if I disable DroidSans, the 'fi' ligature is picked up from the times roman base14 font | 12:31.49 |
| | if I look at DroidSans.ttf with fontforge, there is a 'fi' ligature character... | 12:32.07 |
| Robin_Watts | so the problem is we're falling back to DroidSans rather than Times Roman ? | 12:32.43 |
| | or rather, "we are falling back to Droid Sans". | 12:33.05 |
| kens | But you should presumably find the 'fi' from DroidSans as well | 12:33.14 |
| tor7 | no, the problem is we're not finding 'fi' | 12:33.15 |
| Robin_Watts | There are potentially 2 problems here, AIUI. | 12:33.28 |
| tor7 | falling back to droidsans is the desired behaviour (because it has better glyph coverage than our base14 times roman) | 12:33.41 |
| Robin_Watts | 1) We are falling back to Droid Sans when we should be falling back to Times Roman in this case. | 12:33.50 |
| tor7 | compile with -DNODROIDFONT makes fallbacks to base14 | 12:33.58 |
| Robin_Watts | 2) We aren't finding the fi in DroidSans. | 12:34.00 |
| tor7 | 1) we only use Times Roman if the font is times roman. the current font pretends to be a subset font (it has the ABCDEF+ prefix) but no embedded font file | 12:34.34 |
| kens | THat's terrible | 12:34.47 |
| tor7 | 2) we aren't finding 'fi' is bad | 12:34.53 |
| kens | What created that abomination ? | 12:34.55 |
| Robin_Watts | Is it a subset font of Times Roman ? | 12:35.00 |
| tor7 | Robin_Watts: it looks like it should be a subset font of times roman, but it's missing the subset font part, so we're treating it as a generic "missing font" case | 12:35.31 |
| | which always falls back to our substitute font, which happens to be droid sans | 12:35.46 |
| | we could extend the set of subset fonts (and bloat the binary) | 12:35.56 |
| | to provide a serif fallback font as well, for instance | 12:36.08 |
| | I'm not wedded to the particulars, but droidsans was small and has good glyph coverage | 12:36.28 |
| Robin_Watts | could we say "if this claims to be a subset of one of our base14 fonts, fall back to the base14 rather than droidsans" ? | 12:36.45 |
| tor7 | and it's fairly compact (narrow) so it works decently when stretching it to fit the metrics | 12:36.50 |
| Robin_Watts | but at any rate 2) seems to be the problem to solve first :) | 12:37.02 |
| tor7 | Robin_Watts: but then we might be missing even more glyphs than 'fi', because our base14 fonts don't have the extensive unicode coverage that things like windos Times.ttf does | 12:37.24 |
| Robin_Watts | It's a shame we can't have multiple fallback fonts. | 12:37.37 |
| tor7 | we only have what the pdf spec requires of the base 14 fonts | 12:37.39 |
| | which is essentially latin-1 and a bit | 12:37.51 |
| | Robin_Watts: we can, but how many megabytes do you want to add? | 12:38.05 |
| Robin_Watts | no, sorry, not like that. | 12:38.17 |
| tor7 | anyway, the bigger issue here is not finding the 'fi' glyph | 12:38.18 |
| | Robin_Watts: if you compile with -DNODROIDFONT, we use the base 14 fonts as fallback fonts by picking the closest family (serif/sans, bold/italic, mono/prop) | 12:38.56 |
| Robin_Watts | I meant, I'd like to have an fz_font that looked first in one font for a glyph, then if it didn't find it there, it would look in another font for the glyph, then if it didn't find it there, look in another font.... | 12:39.03 |
| tor7 | Robin_Watts: that would look terrible... | 12:39.17 |
| kens | Oh yuck, inconsistent glyphs next door to each other, icky bad | 12:39.24 |
| Robin_Watts | kens: preferable to not finding glyphs though. | 12:39.48 |
| tor7 | I'd rather have it fall back to a consistently ugly font that has everything | 12:39.49 |
| kens | Robin_Watts : IMO not really, but I'm thinking of print | 12:40.10 |
| tor7 | which the droidsans is supposed to have in theory (latin-1, -2, greek) | 12:40.13 |
| | and cyrillic | 12:40.26 |
| Robin_Watts | I'm just thinking that in this case, we ought to use Times Roman rather than DroidSans. | 12:40.44 |
| | but the tradeoff there is that we might lose glyphs if we do that. | 12:41.09 |
| | Hence using Times Roman with a further fallback to DroidSans would solve that. | 12:41.30 |
| | but again, we need to solve 2) first. | 12:41.41 |
| tor7 | Robin_Watts: if the font had been named "Times Roman" instead of "ABCDEF+Times Roman" we would be using Times | 12:41.46 |
| | but the file lied to us about what it is, so we don't | 12:42.04 |
| | okay, so FT_Get_Name_Index() on the droidsans.ttf file fails to find 'fi' but finds most other glyphs | 12:47.06 |
| | which suggests the 'post' table is incomplete | 12:48.04 |
| Robin_Watts | OK, so, as we've discovered, I know nothing about fonts. What happens in Acrobat if you tell it to display some text in a font that doesn't contain all the required glyphs? (I'm thinking of a form field that I've edited to have new entries in) | 12:48.25 |
| Robin_Watts | goes to get food before chaos descends this afternoon. | 12:48.48 |
| tor7 | Robin_Watts: ohh... it's using the 'uniFB01' name rather than 'fi' | 12:49.22 |
| | I guess we should add a list of aliases for glyph names to try... | 12:49.52 |
| | oh, we already do (pdf_lookup_agl_duplicates) | 12:52.36 |
| | but I guess that one doesn't cover the uniXXXX case | 12:52.44 |
| | Robin_Watts: that's the same question I keep asking paul how he intends to solve :) | 12:57.15 |
| | and why I keep proposing to "screw the fonts that came with the file, always use our own" | 12:57.35 |
| | Robin_Watts: tor/master has a fix for finding 'fi' in DroidSans.ttf | 12:58.46 |
| paulgardiner | Robin_Watts, tor7: Signing and verification seems to be working on Android - four commits on paul/android-signatures | 14:30.05 |
| Robin_Watts | nice one. | 14:30.14 |
| tor7 | Robin_Watts: did you see my latest on tor/master? I have a fix for the customer's ligature bug thingy | 14:30.52 |
| Robin_Watts | tor7: I did, but I'm surrounded by bits of the glyph cache at the moment :) | 14:31.24 |
| kens | chrisl bug 694534 :-( | 14:38.17 |
| | Why does nobody test the release candidate ? | 14:38.40 |
| chrisl | kens: saw it :-( | 14:38.42 |
| | I'm tempted to comment on that in the bug report | 14:38.57 |
| kens | Feel free..... | 14:39.06 |
| | I notice that he is using gv | 14:40.07 |
| chrisl | Yeh, I didn't notice it did different things for PDF :-( | 14:40.27 |
| kens | Oh pdf2dsc, I wonder what *that* does, I;'m inclined to deprecate it | 14:40.35 |
| | Of course the file is using undocumented internal operators again | 14:41.28 |
| | Just like gsview | 14:41.34 |
| | I can't even figure out what pdf2dsc.ps is supposed to be doing | 14:43.14 |
| chrisl | Stuff that's really pointless for a PDF, I reckon.... | 14:43.48 |
| kens | I'm inclined to agree | 14:44.01 |
| | What is a DSC "index" file anyway ? | 14:44.17 |
| Robin_Watts | pops out for a bit. | 14:44.33 |
| chrisl | kens: no idea. FWIW, it doesn't seem to stop gv working, at least for basic vewing | 14:45.22 |
| kens | chrisl whatever this is its not killing the release again, it looks dumb to me | 14:45.47 |
| chrisl | I'm astonished anyone is using gv - it's a pile of sh*t..... | 14:46.30 |
| kens | THe basic problem is the same (but subtly different) to the GSView problem, and again its using undocumented internal operators. | 14:46.58 |
| chrisl | kens: If I comment out the offending line, it seems to make no difference - at least, at first glance | 14:49.22 |
| kens | Hmm, I would expect it to. I'm still struggling with getting it to do something in Windows | 14:49.53 |
| | OK well I can reproduce the invalidaccess | 14:51.12 |
| | chrisl you have COMPILE_ININTS=1 ? | 14:51.44 |
| chrisl | Yes | 14:51.53 |
| kens | THen it finds pdf2dsc in the ROM file system unless you put a fully qualified paht in (ie don't use the script) | 14:52.19 |
| chrisl | No, we don't build lib into the romfs | 14:52.49 |
| kens | Oh. Well possibly the problem is the output still contains a .setsafe | 14:53.11 |
| | All tit does is wrap a (<pdf name>) run with some DSC comments | 14:53.37 |
| | Useless ones | 14:53.47 |
| chrisl | Hmm, yeh. But as I said, just removing that offending line seems to let it work..... strange | 14:55.20 |
| kens | Well tht .setsafe causes an invalidacess error (moral don't use internal routines) | 14:55.47 |
| | The one in the emitted file is wrapped in a stop so its OK | 14:56.00 |
| chrisl | Yeh, but given that just removing it seems to have no adverse effects, why is it there? | 14:56.28 |
| kens | Its sets the 'safer' mode | 14:56.38 |
| | Well, I'll just remove the line, it does nothing useful IMO | 14:57.14 |
| chrisl | SAFER is a command line option, it should be set from there..... | 14:57.37 |
| kens | Yes, and the script sets it there too..... | 14:57.54 |
| | I see what its doing, and its pretty hacky | 14:58.17 |
| | Its to allow gv to handle a PDF file and page back and forth | 14:58.29 |
| | Its using internal PDF interpreter commands to show each page individually (more use of undocumented internal routines) | 14:58.56 |
| | and each page is wrapped in DSC comments, just so gv can handle it. | 14:59.14 |
| chrisl | It's seems like a hack just to avoid handling PDF properly..... | 14:59.46 |
| kens | Exactly so | 14:59.52 |
| | And if I change teh PDF interpreter its entirely possible those routines will work differently, and so it will stop working altogether | 15:00.32 |
| chrisl | I'm rather surprised it hasn't already happened..... | 15:00.53 |
| kens | Frankly so am I :-) | 15:01.08 |
| | I'll make the change to the ps file and leave it at that. | 15:01.19 |
| kens | seriously considers removing a load of the scripts from 'lib' | 15:04.15 |
| | And it looks like Tim Waugh has identifed a typo, but isn't going to share it. | 15:07.47 |
| chrisl | Whoopee - my car is ready. I'm going to head to collect it....... | 15:08.07 |
| kens | bye.... | 15:08.16 |
| ray_laptop | can someone with the 64 bit MSVC installed build a debug 64-bit binary for me, please ? any recent version (9.09 or HEAD) is fine. I've tried a couple of times and the tools won't install correctly for me. I need this for a P2 bug | 15:23.35 |
| kens | ray_laptop : you actuallly want to debug it ? If so you need the bsc files too, and they will be built to match the source file locations on my machine not yours, so I don't think it will work | 15:31.47 |
| ray_laptop | kens: I don't need to debug it. I just need to be able to see the -Za output and that is only enabled with a DEBUG=1 build | 15:50.28 |
| kens | ray OK I'll put the binary on peeves, one minute | 15:51.40 |
| ray_laptop | kens: great! yet another strange regression on 9.09 (the .setsafe problem with pdf2dsc), but I am re-opening the bug as .setsafe *is* documented in doc/Language.htm | 15:58.40 |
| kens | What ? I don't think it should be. | 15:58.57 |
| ray_laptop | kens: thanks for the binary. | 15:59.07 |
| kens | Oh it only just finished here | 15:59.20 |
| | Its the DLL and the 2 executables | 15:59.28 |
| ray_laptop | kens: thanks | 16:00.43 |
| | kens: .setsafe is needed to allow running an input file SAFER mode, after opening files that may not be allowed to be opened in SAFER mode | 16:01.40 |
| kens | More strange Ghostscript weirdness. | 16:01.51 |
| | THis is all pants frankly | 16:01.57 |
| | Too many weird and wonderful command line switches | 16:02.15 |
| | and PostScript extensions | 16:02.21 |
| ray_laptop | kens: this was VERY important to the unix community that wanted to protect servers from malicious PS files | 16:02.40 |
| kens | SAFER protexts things, -dNOSAFER doesn't | 16:02.54 |
| | -dNOSAFER followed by .setsafe is what I'm referring to, which is 'not safer, oh I mean yes safer' or so it appears | 16:03.25 |
| ray_laptop | the pdf2dsc.ps script needs to open the PDFfile in NOSAFER mode, then enter SAFER mode. | 16:03.48 |
| kens | stands by my opinion | 16:04.20 |
| ray_laptop | while a real PDF file doesn't really need SAFER mode since it doesn't do any actual file operations other than reading that is done by the PDF interpreter, a PS file sent to pdf2dsc *could* wreak havoc, particularly if the script has some powerful permissions | 16:06.40 |
| kens | OK we are buggered I believe. Its impossible to fix the original bug *and* have /.setsafe work *and* have Display PostScript work. | 16:07.17 |
| | Pick any 2 | 16:07.26 |
| ray_laptop | kens: what is 'fix the original bug' ? | 16:11.12 |
| kens | I no longer remember.... | 16:11.27 |
| | SOmething to do with setpagedevice when the VM allocation mode is global | 16:11.43 |
| ray_laptop | and how is DPS involved ? | 16:11.44 |
| kens | Ray, you need to go read the original commit for details, and teh subsequent ones | 16:11.59 |
| ray_laptop | what is the "original commit" ? I'll be glad to read it | 16:12.19 |
| kens | THat's one of them: | 16:12.53 |
| | 939e32ff3c8841507aed80435269457f3caac6f5 | 16:12.53 |
| ray_laptop | kens: I'll take the latest bug 694534 since I wrote most of the safe mode stuff (with LOTS of design discussion amongst Raph, Ralph, and Till, and probably Igor and Alex) | 16:13.51 |
| kens | You'd probably better leave it with me for now | 16:14.09 |
| ray_laptop | kens: thanks for the binaries and the info | 16:14.21 |
| | kens: OK, if you want it. | 16:14.30 |
| kens | I can't say I *want* it but I understood the problem at one time, now I just have to come up with some Heath Robinson result that will let all the crappiness still work | 16:14.59 |
| | Wel... that 'seems' to work. Now all I have to do is rerun the other cases and see if they all still work | 16:17.17 |
| | Ah, so I have to rebuild with COMPILE_INITS=0 | 16:17.58 |
| ray_laptop | I think we may need to go to a release process where we issue a release (maybe odd numbers) so people will actually start testing it, then follow it up with a "real" release after a bit. The Release Candidate doesn't seem to get any actual testing from anybody out there | 16:18.37 |
| kens | As far as I can see, *nobody* tested it | 16:18.54 |
| ray_laptop | kens: I think you are right. Everybody just waits for the release, then complains | 16:19.32 |
| kens | :-( | 16:19.40 |
| ray_laptop | the thing that is somewhat 'involved' in safer mode is still allowing all of the LIBPATH directories to be readable (the PermitFileReading list of paths with wildcards) | 16:21.09 |
| kens | ray_laptop : I *think* this will work, its hacky, but I believe it covers the cases I know about. Heaven knows how many more there are that I don't know about (yet....) | 16:21.21 |
| | ray_laptop : its not the safer mode per se that is the prroblem, its the VM state of the page device dictioanry and the initial graphics state | 16:21.44 |
| ray_laptop | kens: why don't you push a commit to your git directory, and I promise I will actually look it over promptly | 16:22.00 |
| kens | ray give me a few minutes to do some tests, I think I know where all the previous bodies are buried | 16:22.29 |
| ray_laptop | kens: I assume that you will include reverting the change to pdf2dsc.ps | 16:22.39 |
| kens | If this works, yes | 16:22.48 |
| ray_laptop | kens: no rush, I'll watch for the 'review requested' email | 16:22.58 |
| | in the meantime, I'll work on cust 801 issues | 16:23.37 |
| | and now that 9.09 is out, wrap up the saved-pages work | 16:24.03 |
| kens | I wouldn't do that yet | 16:24.17 |
| | I'm concerned that if so many apps on Linux use pdf2dsc we'll ahve to do YET ANOTHER release | 16:24.41 |
| | OK so GSView still works | 16:25.42 |
| ray_laptop | BTW, changing the pdf2dsc script to use ps2write instead of pdf2dsc.ps might not be a bad idea going forward | 16:26.44 |
| Robin_Watts | testing the glyph cache rework now. tor7: code on robin/master if you want to look, though if you want to wait for the tests to pass I'd understand :) | 16:27.07 |
| kens | Eh ? THat's not really going to fly I think. THe script creates a new PostScript file which runs individual pages fomr the PDF file, wrapped up with DSC comments | 16:27.21 |
| | GS_LIB still works and -dSAFER still works, getting xlose now | 16:30.08 |
| | OK and finally global VM mode dictionaries passed to setpagedevice also work. | 16:32.09 |
| ray_laptop | kens: Oh, yuck. Yes, I just looked at it. What a hack, all for the sake of people that want fake PS. Well, at least it wasn't me that wrote the original :-) | 16:33.05 |
| | kens: maybe test with a -I path that is not in your local directory as well | 16:33.06 |
| | something like -Ic:/Resource/Init | 16:33.39 |
| kens | I already did that with the GS_LIB test | 16:33.58 |
| ray_laptop | in -dSAFER mode | 16:34.00 |
| kens | and in both modes | 16:34.06 |
| ray_laptop | kens: thanks just trying to recall some of the combos that we often see | 16:34.38 |
| kens | These ones I've done before (and teh trickery with GSView) | 16:35.08 |
| ray_laptop | I didn't realize that cust 530 had moved up to P1. Wow, our first top-ten mupdf customer ! | 16:43.46 |
| | I don't count cust 580, even though they do use mupdf, since most of what they take is GS. Not even sure if they are paying extra for mupdf since they may be restricted with what they can do with it | 16:45.32 |
| kens | ray_laptop : I believe (unless I've screwed up Git) that there is now a patch in my repository on casper, in the branch called VMmode | 16:46.38 |
| | Effectively this ulls the /.locksafe change I did before one level higher | 16:47.35 |
| ray_laptop | kens: I'll see if I can look at it ... | 16:48.19 |
| | kens: OK. So .setsafeglobal is now an undocumented internal only kind of function. There is no reason a client needs it ? and why is it that we need it ? Your commit on the branch didn't have any info in the log message, and the code isn't commented as the "why" it is needed | 16:54.50 |
| kens | ray its cvommented in the commit that changed it all, 939e32ff3c8841507aed80435269457f3caac6f5 | 16:55.34 |
| | Because DPS insists that all objects reside in global VM, we need to allocate the device dict in global VM, not local | 16:56.19 |
| | The previous commit 073f7be1671e7fa2dbbc75984e593d2279bb05d7 forced everything to local, so that we didn't get a VM problem | 16:57.10 |
| | But if we do that, then DPS doesn't work, which is why (during startup *only*) we call .setsafe in global VM mode (we only do this if SAFER is set) | 16:57.52 |
| | That allows us to have the inital graphics state be totally in global VM (so DPS is happy), even if we start up in -dSAFER mode, but later page device dicts will be in local VM, to keep everyone happy there. | 16:58.50 |
| | THis all worked fine as long as nobody calls /.setsafe or /.locksafe | 16:59.07 |
| ray_laptop | kens: I think the explanation should go in this commit log as well, but I'll have a look at that one. | 16:59.29 |
| kens | THe log is only a holding place | 16:59.42 |
| | THis is on a branch and I didn't want to write all this up (again) for a temporary commit | 17:00.00 |
| ray_laptop | kens: Yes, I understand | 17:00.31 |
| kens | The trickery is in setpagedevice, where we look for LockSafetyParamsGlobal, if we find that then we make the VM mode global, and replace the key with /LockSafetyParams, otherwise we set the VM mode to local. | 17:01.36 |
| ray_laptop | kens: did you check the sequence with -dNOSAFER doing: save .setsafe restore ? | 17:05.00 |
| | kens: see the server 'helper' docs about .runandhide that is designed to allow a job server to have priveleges, but the individual jobs to run under 'safe mode' restrictions | 17:05.07 |
| kens | ray_laptop : no I didn't try that | 17:05.19 |
| | Isn't that part of the PS file m? | 17:05.26 |
| | ray_laptop : that gets me a invalidacccess in setpagedevice | 17:06.17 |
| ray_laptop | I don't recall offhand which customer(s) that was for, but they use a job server loop in order to avoid starting and stopping gs | 17:06.32 |
| kens | Oh, .setsafe is giving me an error now, I wonder what I just did | 17:06.57 |
| ray_laptop | and since gs is open source, they didn't want a PS file to be able to "find" the save object and restore to unsafe mode | 17:07.46 |
| | but .runandhide certainly hasn't been widely used, AFAIK | 17:08.56 |
| kens | Hmm, .setsafe isn't working, but when I run the PS file it does, that's...odd. | 17:09.38 |
| ray_laptop | Raph was pretty insistent at the time that we protect against things. | 17:09.48 |
| | kens: you mean typing .setsafe to the GS> prompt ? | 17:10.08 |
| kens | yes | 17:10.15 |
| ray_laptop | kens: there is/was a problem I fixed a while ago because of the VM location of the string used for prompting, iirc | 17:10.54 |
| kens | Oh silly me, I went and checked out master | 17:10.56 |
| | OK that works now <relief> | 17:11.50 |
| | ray save .setsafe restore works, what were you expecting to happen ? | 17:12.27 |
| ray_laptop | kens: see the log message for 2fe30fef7a2ae36b34e5ca1de3426b813e717736 that was another setsafe problem | 17:12.36 |
| | after the restore, we should no longer be "locked" | 17:12.58 |
| kens | what was the log ? I can't find things from the commit | 17:13.01 |
| | How do I tell if we are locked ? | 17:13.10 |
| ray_laptop | kens: do you have msysgit running ? If so, just do git log then /setsafe<enter> then n to go to successive log messages mentioning setsafe | 17:14.21 |
| kens | I can do that from the web interface, but I can't search for the commit SHA, just knowing it says setsafe is enough | 17:16.57 |
| | And how do I tell if GS is 'locked' after the save | 17:17.10 |
| | .setsafe restore ? | 17:17.14 |
| ray_laptop | currentuserparams /LockFilePermissions get = | 17:17.19 |
| kens | false | 17:17.41 |
| | THat is starting with -dNOSAFER | 17:17.55 |
| ray_laptop | false means unlocked (unsafe) | 17:17.58 |
| | after .setsafe it will be true | 17:18.09 |
| kens | Yes its true in the middle and flase after teh restore | 17:19.03 |
| | I don't believe 2fe30f can be affected by this, since that's changes in the C code, not the PostScript | 17:19.59 |
| ray_laptop | kens: also: currentpagedevice /.LockSafetyParams get = | 17:20.25 |
| kens | ray_laptop : its time for me to go, I'll leave the testing up to you | 17:20.43 |
| | Goodnight all | 17:20.52 |
| ray_laptop | kens: OK, I'll play with it a bit. | 17:20.58 |
| | g'nite | 17:21.01 |
| | time to go to a doctor's appt. bbiaw | 17:22.10 |
| tor7 | Robin_Watts: all the repeated unlink/relink stuff might be more readable if done in static inline functions | 19:23.05 |
| | otherwise, looks fine (if it passes tests) | 19:23.19 |
| Robin_Watts | tor7: Paths are oddly broken in cluster tests here. | 19:51.12 |
| | I hope it's your path commit not my stuff :) | 19:51.31 |
| | yeah, static inlines are a good idea. New version up with that in. | 19:55.36 |
| ray_laptop | Robin_Watts: cust 532 has run length clip paths implemented in their ASIC (as well as bit blit, of course). And Raph's original 'libart' used RLE buffers (the first implementaion of what (d)evolved into the gs transparency code) | 21:39.11 |
| Robin_Watts | ray_laptop: Yeah, I think there is more than enough prior art for generating RLEd bitmaps from a mask. | 21:39.49 |
| | Picsels cleverness was (IMHO) in the way they went from the output of a scan converter to on/off/edges without going via the bitmap stage. | 21:40.17 |
| ray_laptop | Robin_Watts: I guess I don't understand what the output of the scan converter is other than left-right edges | 21:47.14 |
| | the more complex problem is going from path polygons to traps, I thought. The line-by-line approach is what's been around since the 60's | 21:48.26 |
| Robin_Watts | ray_laptop: The output of the scan-converter is left-right edges, yes. | 22:38.17 |
| | Picsel generates left-right edges for 'sub scanlines' (4 subscanlines gets you 2 bits of AA) | 22:39.21 |
| | The trick is that they then go from these left/right edges to runs of on pixels/off pixels/edge pixels without going through an intermediate bitmap state. | 22:40.10 |
| | we go to a coverage bitmap and work from that. they avoid the coverage bitmap. | 22:40.50 |
| toothr | good evening | 23:36.52 |
| | Forward 1 day (to 2013/08/23)>>> | |
IRC Logs