| <<<Back 1 day (to 2013/06/30) | 2013/07/01 |
hypnocat | has anyone else had zathura repeatedly blank the screen while printing "Loading..." on them? | 01:41.47 |
| or, more to the point, know how to fix it? | 01:41.53 |
| this is happening for me with the mupdf backend | 01:42.14 |
| the problem does not appear to happen with mupdf itself.. so i guess this is a zathura issue | 01:45.13 |
kens | falls into macro hell again.... | 07:08.34 |
sebras | hypnocat: does this happen just with a particular pdf? can you share it? | 07:31.21 |
kens | wonders if we really need to build Display PostScript into the default GS build.... | 09:44.27 |
Robin_Watts | kens: What's the disadvantage of building it in? | 09:45.32 |
kens | Robin_Watts : its slower for one thing, and defines a load of stuff we don't need (and it breks my change with -dSAFER) | 09:45.59 |
chrisl | kens: I guess the only thing is there is at least project out there that depends on DPS, so we probably need to avoid breaking it - and they may rely on it being in libgs.so | 09:51.26 |
kens | :-( | 09:51.36 |
| A never widely used hack of a language that's been obselete for decades.... | 09:51.58 |
chrisl | Somebody loves it..... | 09:52.19 |
kens | In any event, I was more wondering why its in the default build than anything else. | 09:52.20 |
| Surely the one weird project could build it that way themelves.... | 09:52.33 |
chrisl | Distribution policies.... must.... use.... shared..... libs...... | 09:53.04 |
kens | :-) | 09:53.13 |
| I was just thinking, that probably doesn;t work with things like FreeType | 09:53.40 |
| If you rely on building it in a particular way (say a specific CFF parser) | 09:53.55 |
chrisl | Why would it not work with freetype? | 09:54.39 |
kens | Say your partic ular use depends on a CFF parser which isn't the (now) default one ? | 09:55.04 |
| You need a non-defualt parser, the system lib is built with teh default one.... | 09:55.24 |
| I feel sure there must be other things that would break similarly with other libraries, otherwise what's the point of the build options ? | 09:55.58 |
chrisl | I don't follow - DPS is still just interpreting Postscript, isn't it? | 09:56.17 |
kens | If only it were.... | 09:56.30 |
| It messes with our startup code, and has 'interesting' requirements | 09:56.50 |
| Though in reality, its not really the problem, I just came across it while chasing this problem | 09:57.29 |
| Its a bit like that one the other day where we store an opaque pointer to a C structure in a PostScript object. I hadn't realised before that the graphics state structure stores an opaque pointer to a Postscript dictionary | 09:58.31 |
chrisl | Ugh.... why? | 09:59.07 |
kens | So it can return it in response to currentpagedevice | 09:59.26 |
chrisl | Erm, surely you need to build the dictionary based on the settings in the current device? | 10:00.04 |
kens | Yes, and once that's done we store the pointer to the dictioanry in a C structure..... | 10:00.30 |
| Its in zsetpagdevice I htink. | 10:00.45 |
| istate->pagedevice = *op; | 10:00.57 |
| where *op is the page device (PostScript) dictioanry | 10:01.10 |
| istate is i_ctx_p->pgs->client_data | 10:01.38 |
| and tehn in currentpagdevice we do: | 10:02.04 |
| op[-1] = istate->pagedevice; | 10:02.04 |
| make_true(op); | 10:02.04 |
chrisl | Oh, so it's not really graphics state, it's the interpreter context | 10:02.09 |
kens | Well, its the graphics state in the interpreter context. | 10:02.48 |
| hte 'int_gstate' | 10:02.55 |
chrisl | But that dictionary does not necessarily reflect the current state of the current page device, so it's wrong..... | 10:03.46 |
kens | Err, it does, because that's the dictioanry which is created during the course of setpagedevice. | 10:04.07 |
| Its only 'wrong' if you change the device without changing the dictionary (which is possible, and a Bad Thing) | 10:04.28 |
chrisl | Well, what about devices changing due to hardware interaction, and the like? | 10:05.07 |
kens | Not sure what you mean, all the merging and stuff is done in PostScript. | 10:05.32 |
chrisl | Something like running out of a particular media size | 10:06.09 |
kens | How could we tell ? | 10:06.20 |
chrisl | If you're driving "real" hardware..... | 10:07.04 |
kens | Well in that case something would have to tell GS and it would do it by calling setpagedevice | 10:07.24 |
chrisl | It's a good job it's so easy to call Postscript from the C world, then, isn't it? | 10:07.58 |
kens | :-) | 10:08.02 |
| What's really cauing me confusion is this bit in gs_init.ps: | 10:08.24 |
| % Establish local VM as the default. | 10:08.24 |
| //false /setglobal where { pop setglobal } { .setglobal } ifelse | 10:08.24 |
| $error /.nosetlocal //false put | 10:08.24 |
chrisl | Anyway, given that the implementation is as it is, why store a pointer like that? Why not store it in systemdict? | 10:08.38 |
kens | Before that, 'currentpagdevice /OutputAttributes get gcheck ==' returns true, afterwards it returns false *no matter what the VM allocaiton mode is* | 10:09.07 |
| Snd I cannot find anywhere that OutputAttributes gets recreated | 10:09.36 |
| So its as if it changes the allocation mode of an allocted object (!!) | 10:09.50 |
chrisl | I wonder why we check for the existence of setglobal there..... | 10:15.31 |
kens | We either use the PostScript one, or if its not defined, our own internal operator (bizarre I know....) | 10:17.16 |
chrisl | I just rather thought that given that it's *our* Postscript we'd what whether a particular operator was defined or not at a given point..... | 10:18.02 |
kens | LOL what did I just say about Display PostScript ? | 10:18.26 |
| THings can chage, depending on our configuration. | 10:18.38 |
| Not I grant you DPS in this case, but.... | 10:18.46 |
| We use the PostScript one anyway | 10:20.08 |
| Which seems to be mapped to /setshared, whatever that is | 10:21.03 |
| Ah well that is defined in gs_dps1, one of the Display PostScript files.... | 10:21.46 |
| THough not (I htink) until after the initialisation code has executed. SO I guess its really calling .setglobal, confused yet ? | 10:22.22 |
chrisl | Bonkers :-( | 10:22.52 |
kens | And it still doesn't explain why my dictioanry changes vm allocation mode :( | 10:23.21 |
chrisl | maybe .makecurrentpagedevice in gs_setpd.ps? | 10:24.05 |
Robin_Watts | paulgardiner: Hey. | 10:24.41 |
kens | Hmm, I though that the dictioanry was returned directly from zcurrentpagedevice, but maybe no. | 10:24.43 |
paulgardiner | Robin_Watts: Ho | 10:25.08 |
chrisl | kens: currentpagedevice is redefined in gs_setpd.ps - line 289 | 10:25.16 |
kens | bangs head repeatedly against wall | 10:25.28 |
Robin_Watts | So, I pushed through a change last week to support the incremental loading stuff, whereby pdf_obj's now how have pdf_document * pointer rather than an fz_context pointer. | 10:25.30 |
paulgardiner | Yep... which my later commit relied on | 10:25.54 |
Robin_Watts | and zeniko points out that this causes problems | 10:26.22 |
kens | needs more coffee before tackling this one | 10:26.43 |
Robin_Watts | when we close a document, any extant pdf objects are left holding a duff document pointer. | 10:26.56 |
paulgardiner | Hmmm. That's a pain. I guess objects were sort of independent of docs before. | 10:28.35 |
Robin_Watts | type3 font resources are the example he uses. | 10:28.50 |
| Personally, I think pdf objects *should* be tied to the docs. | 10:29.28 |
| cos if you have an object that has an indirect object in it, then it damn well better be associated with a doc. | 10:29.53 |
| and the parent pointer only makes sense with a doc. | 10:30.24 |
paulgardiner | Oh yes. Good point. Indirect objs are meaningless without the doc | 10:30.36 |
Robin_Watts | So, either we need to stop pdf objects persisting after a document is closed, or we need to make pdf_document reference counted. | 10:31.08 |
| that way closing a document won't actually close the document until all the refs have gone away. | 10:31.31 |
| sebras: You may have opinions on this too. | 10:31.39 |
paulgardiner | Would reference counting work? Wouldn't we get into a nasty circularity problem | 10:31.50 |
Robin_Watts | go on... | 10:32.07 |
paulgardiner | Since xrefs entries hold rerferences to pdf objs | 10:32.26 |
| I guess we could blow them all away because they are only a cache | 10:32.46 |
Robin_Watts | I was thinking that the font reference would hold a reference to pdf_document. | 10:32.53 |
paulgardiner | The other way to do this would be to have all functions that make use of parent_num take the doc as arg. | 10:34.34 |
Robin_Watts | Actually, since we moved to using display lists for type3 fonts, and loading all the glyphs to display lists up front, I'm wondering if we can't solve this a different way... | 10:34.47 |
paulgardiner | Hmmm maybe not, that would include all users of pdf_dict_put | 10:37.48 |
Robin_Watts | It used to be that to render type 3 glyphs, we needed to be able to interpret the charprocs at page display time. | 10:40.12 |
| BUT with multi threading, that became a problem, as we can't have multiple threads hitting the file at the same time. | 10:40.52 |
| So we moved to converting all type3 fonts to display lists at load time. | 10:41.10 |
| hence after load, you'd think that we don't need to have the font resources any more. | 10:42.17 |
| There are a couple of wrinkles with type 3 fonts that I need to think through though. | 10:43.09 |
paulgardiner | I'm surprised that any of the code that used pdf_objs after the doc had gone away, did anything with them that caused the doc to be refered to. | 10:43.44 |
Robin_Watts | paulgardiner: I'm wondering if they don't. | 10:44.09 |
| But the problem is that the code to free a pdf_obj relies on going obj->doc->ctx to get a context to use to free the obj. | 10:44.37 |
| Another solution would be for pdf_obj's not to have a doc pointer, but to have a pointer to a new struct { fz_context *ctx; pdf_document *doc }; | 10:45.20 |
paulgardiner | oh I see | 10:45.26 |
Robin_Watts | that way they could still get a ctx pointer after the doc had died. But that's horrid. And would require more refcounting. | 10:45.48 |
| kens, paulgardiner : http://www.ebay.co.uk/itm/Sennheiser-PXC-350-Headband-Headphones-Black-Noise-Block-Cancellation-Cancelling-/330945632851?clk_rvr_id=496261395209 | 11:07.01 |
| "Found in a miami hotel" :) | 11:07.14 |
kens | Not mine, I'm glad to say | 11:09.23 |
Robin_Watts | kens: no, sorry, I was joking. | 11:11.02 |
| but it looks like the curent product is the PXC450, and that's 260quid ish on the net :( | 11:11.24 |
| Ah. New ones: http://www.ebay.co.uk/itm/SENNHEISER-PXC350-PXC-350-HEADPHONES-WITH-NOISEGUARD-UK-/370206566587?clk_rvr_id=496265395401 | 11:12.37 |
kens | I bought a replacement pair of 450s | 11:13.37 |
Robin_Watts | kens: oh, right. | 11:17.09 |
paulgardiner | What's the difference 350 vs 450? | 11:17.17 |
Robin_Watts | 100. | 11:17.32 |
kens | :-) | 11:17.46 |
paulgardiner | Thanks. I thought it was somewhere around that. :-) | 11:18.05 |
Robin_Watts | 350's are the ones I've got. | 11:18.18 |
kens | Robin_Watts : you a gun owner now ? | 11:18.23 |
Robin_Watts | They have an inline volume controller (analogue) and no "talk through" | 11:18.37 |
| The 450's have a volume up/down on the ear thing, and a talk through button. | 11:18.58 |
| kens: Can you unplug the cable from the 450s ? | 11:19.09 |
kens | Yes I think so | 11:19.17 |
| Its a replaceable item | 11:19.23 |
Robin_Watts | kens: I have applied for a shotgun license. | 11:19.50 |
| I have fitted shotgun and ammo safes. | 11:20.02 |
kens | Robin_Watts: : | 11:20.05 |
| http://www.theregister.co.uk/2013/07/01/cops_tried_to_gloss_over_database_snafu_that_lost_over_9000_firearms/ | 11:20.05 |
Robin_Watts | so I'm not a gun owner, *yet*. | 11:20.14 |
kens | Yes I remember you dropping the safe on your foot... | 11:20.27 |
Robin_Watts | Typical public service IT. | 11:20.51 |
| I wore shoes for the second safe. Much better :) | 11:22.35 |
sebras | Robin_Watts: paulgardiner: I agree, pdf objects separate from a document are meaningless. they need the xref to refer to other objects. | 11:33.38 |
Robin_Watts | I think the idea of binning the type3 pdf object references as soon as we finish loading the type3 fonts is working. I got 44 differences in the cluster tests, but I think they are down to other commits. Retrying now. | 11:35.05 |
| There look to be 3 files in our test suite that cause differences. investigating. | 11:42.53 |
kens | chrisl I finally found it.... | 11:53.46 |
| Its to fix a WorPerfect bug. | 11:53.58 |
chrisl | kens: nice one! | 12:06.28 |
kens | chrisl its essentially unfixable I think. I can't have the fix for the WordPerfect files, and at the same time cope with setpagedevice when the current allocation mode is global | 12:07.06 |
chrisl | Oh, so Wordperfect wants to write directory to the dictionary that comes from currentpagedevice? | 12:09.41 |
kens | seems that way yes, and it assumes they are local as well according to the comment | 12:10.04 |
| I *may* be able to work around this, but as ther eis no bug number in the comment, I can't test if the WP fix will still work. | 12:10.32 |
chrisl | I wonder if there is a better solution to that | 12:10.38 |
kens | Possibly, but.... No test file :-( | 12:10.54 |
| I'm just playing with setpagdevice, I may be able to fix it in there, which gets away from any problems with WP files (though who cares about WP now ? oh yes, someone somehwere will have it as a critical pice of their process.....) | 12:11.54 |
chrisl | Hmm, yes, that predates available history :-( | 12:16.46 |
kens | I'm not suprised, when was hte last time you heard of anyone using WordPerfect ? | 12:17.11 |
| Thgough (oh oh) Corel still sells it..... | 12:17.35 |
chrisl | It may not have the same buggy PS output, though | 12:18.02 |
| I have a feeling I fixed a WordPerfect idiom in Jaws...... | 12:18.07 |
kens | I bet it dies :-) | 12:18.12 |
| does | 12:18.15 |
chrisl | Maybe we should fix GS's idiom recognition | 12:18.44 |
kens | I think I cna fix this in setpagedevice by copying the local dict to a global one before calling setpagedevice. | 12:18.48 |
| Though whether that will work with the WP file is debatable | 12:19.02 |
| If I get this fixed I'll cluster test it and see what happens | 12:19.21 |
chrisl | We don't seem to have any WP PS jobs in our test suite. | 12:20.28 |
kens | Then I'm probably safe :-) | 12:20.37 |
chrisl | In a situation like this, the only solution is probably to throw it out into the world, and see if someone complains | 12:22.08 |
kens | First I have to come up with a solution :-( | 12:22.25 |
sebras | did tor8 forget to wake up this morning? | 12:31.24 |
| nvm. I remember now. | 12:31.47 |
kens | chrisl do you know if we have any 'deep copy' routines available in GS ? I want to copy all the contents of a dictionary from local to global VM objects, recursively of course. | 12:36.48 |
chrisl | kens: I haven't seen one...... | 12:37.13 |
kens | OK so I'll have to write my own, NP thanks | 12:37.27 |
mvrhel_laptop | good morning | 12:38.54 |
kens | Mornign mvrhel_laptop | 12:39.01 |
| I sent a transparncy problem your way over the weekend | 12:39.11 |
mvrhel_laptop | kens: yes the knockout text. thanks.... ;) | 12:39.32 |
kens | mvrhel_laptop : well I couldn't see what I was doing wrong :-( | 12:39.45 |
mvrhel_laptop | I remember getting rid of that one once | 12:39.47 |
| no worries. it will be good for me to take another look at it | 12:40.03 |
kens | mvrhel_laptop : yes, you sent it to Alex, but I implemented your suggestion and it didn't work for me | 12:40.04 |
| Possibly I did it incorrectly of course | 12:40.19 |
mvrhel_laptop | ok. I will look it over this week | 12:40.34 |
kens | THanks | 12:40.38 |
| BTW do note that the default value of Text Knockout is currently incorrect (false), the spec says its initial value is true | 12:41.05 |
mvrhel_laptop | I saw that in your message | 12:41.22 |
kens | OK no problem then | 12:41.36 |
mvrhel_laptop | surprised we had not found that before | 12:41.37 |
kens | Well we don't actually *do* anything with teh value as far as I can tell | 12:41.53 |
| except for pdfwrite which only writes it out if it changes..... | 12:42.07 |
mvrhel_laptop | ok | 12:43.29 |
kens | Of course, that is a point, its possible pdfwrite isn;t writing /TK false when it should be ;-) | 12:43.58 |
| I suppose I should test that file with pdfwrite | 12:44.14 |
| meybe after I get rid of this horrible PS problem | 12:44.29 |
| Duh why does everyone think NumRenderingThreads is going to help ? At 150 dpi ?...... | 12:59.52 |
chrisl | Because threads fix everything - they are the greatest thing since XML..... | 13:01.23 |
mvrhel_laptop | funny | 13:01.35 |
kens | chrisl canyou quickly try the file for #694390 please ? It works just fine on WIndows | 13:01.46 |
| Of coruse the reoprter hasn't bothered to say *what* errors they get, and we know how reliabel someone reporting 'crashes' is | 13:02.13 |
| And its on Linux, so probably packaged up by some distribution, and using shared libraries..... | 13:02.39 |
| My guess is a standard jpeglib or something | 13:03.57 |
chrisl | kens: I'll just do a 9.07 build, and try it | 13:03.59 |
kens | I've booted Linux so I'll try head code | 13:04.13 |
| Dont' think I hvae 9.07 availabel on Linux | 13:04.27 |
| 8.71 installed :-) | 13:04.49 |
| current code works just fine for me | 13:07.20 |
chrisl | 9.07 seg faults | 13:07.38 |
kens | intriguing | 13:07.49 |
| 8.71 is OK too | 13:07.54 |
chrisl | We've fixed a few crashes..... | 13:08.29 |
kens | true | 13:08.47 |
| I'll close it as 'worksforme' and note that 9.07 did crash | 13:09.11 |
| Unless you really want to bisect it, I can't be bothered myslef | 13:09.32 |
chrisl | It crashes in the clist - I'd just close it. | 13:10.04 |
kens | NP as long as yo uare happy too :-) | 13:10.18 |
chrisl | Well, I think we have better ways to spend our time than tracking already fixed bugs! | 13:11.32 |
kens | I certainly do.... | 13:11.41 |
chrisl | Robin_Watts, paulgardiner: I don't think building for WinRT/ARM is going to be quite as easy as we'd hoped :-( | 13:12.46 |
Robin_Watts | chrisl: What's the problem you've hit ? | 13:13.00 |
| chrisl: mvrhel_laptop has mupdf building both on winrt x86 and arm. | 13:13.29 |
| Maybe he can grab command lines for you? | 13:13.44 |
paulgardiner | chrisl: thought it might not be | 13:13.46 |
chrisl | It's a different compiler with a different path to it. When I set stuff up so CCAUX points to the native compiler, I get a bunch of link errors from the "aux" tools | 13:14.02 |
paulgardiner | .. why I was very glad when you said you'd have a look :-) | 13:14.03 |
chrisl | Basically, you are supposed to the "Cross tools for....." when cross compiling, and that sets up the environment for the cross compiler, but then we need access to the native compiler, too :-( | 13:15.47 |
kens | Oh great, his second bug report is a 140 page image, and he 'doesn't know which page is causing trouble' | 13:17.09 |
chrisl | Robin_Watts: it *seems* (guessing a bit) that cl.exe has no built-in knowledge of where it should look for (even default) libraries, and relies on the LIBPATH environment variable (or command line switches) for the library search path | 13:20.59 |
Robin_Watts | chrisl makes sense. | 13:23.17 |
| but we should "just" need to copy the appropriate settings from the setup .bat's. | 13:23.36 |
chrisl | Probably, yes | 13:24.18 |
Robin_Watts | ok, so the multithreaded problem I was worried about was a red herring. | 13:25.07 |
| but the use-after-free is genuine, and ref counting will be problematic as there are circularity issues. | 13:26.08 |
mvrhel_laptop | sorry I was away. | 13:53.07 |
| so what is going on with respect to WinRT etc | 13:53.32 |
| for gs | 13:53.35 |
chrisl | mvrhel_laptop: I was just having a quick exploratory poke at cross compiling gs for WinRT for ARM | 13:54.15 |
| We'd hoped it would be a fairly trivial task, but it's looking a bit more involved. I'll take another look later in the week | 13:54.58 |
mvrhel_laptop | The way that this should be done for windows phone, windows 8 etc is to make a winrt dll for the API calls where we just grab the standard .lib and replicate the API via c++. At least that is the way that I would do it | 13:55.04 |
| I could probably throw that together real quick | 13:55.37 |
chrisl | We already have a WinRT build, it's the cross compiling that's complicating things a bit | 13:55.57 |
Robin_Watts | mvrhel_laptop: The problem is not (as yet) how to expose gs to WinRT apps. | 13:56.13 |
| It's how to actually get an ARM build of what we already have working for x86 | 13:56.30 |
mvrhel_laptop | ah ok | 13:56.57 |
chrisl | Basically, we'll need a way to set compiler and linker options separately for the cross compiler (CC) and native compiler (CCAUX) | 13:57.43 |
paulgardiner | Robin_Watts: fix for android app crashing after save on paul/master | 13:58.06 |
mvrhel_laptop | I can show you the x86 vs ARM command line options for mupdf that I have if you want | 13:58.08 |
| but not sure if that will help you | 13:58.27 |
chrisl | mvrhel_laptop: I figured the command line options would be similar - when I get to the point where that's a problem, I'll ping you about it! | 13:58.56 |
mvrhel_laptop | ok | 13:59.12 |
chrisl | I don't think it's a huge deal (just not as easy as we'd hoped), but it's a little more involved than the equivalent on Linux would be | 14:00.01 |
Robin_Watts | paulgardiner: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=60d5dc8417e5574fb54c74ce04b36c0c81b92eab | 14:58.20 |
| your fix looks fine. will push | 14:59.13 |
paulgardiner | Robin_Watts: yeah. Looks okay to me | 15:06.44 |
Robin_Watts | paulgardiner: Thanks. | 15:07.22 |
| I'll push it and we'll see what Zeniko can find. | 15:07.37 |
mvrhel_laptop | bbiaw | 15:12.27 |
kens | chrisl ping | 15:46.19 |
chrisl | kens: pong | 15:51.35 |
kens | chrisl is there any wway to influence the 'decoding' applied when we load a TrueType font as a substitute for a missing PostScritp font ? (NB not a CIDFont) | 15:52.05 |
chrisl | Hmm, not that I know of, but it's not a feature I've dug into much | 15:52.45 |
kens | I thnk there isn't, but I thought you might know better. I've already emailed Aaron and preached (yet again) the gospel of 'embed the fonts' | 15:53.18 |
chrisl | kens: no, there's nothing the FontMap syntax (that I can see) to allow that - I think you're just stuck with the "heuristics" built-in | 15:54.20 |
kens | Yep, that's what I thought, thanks | 15:54.33 |
chrisl | kens: having said that, I think we go through quite a few hoops to find matches using the AGL, the Unicode glyph names and the TTF psnames | 15:56.09 |
kens | Yeah, but I tried their test file and it came out with missing glyphs (notdef) | 15:56.35 |
chrisl | Hmm, are they using a weird font? | 15:56.53 |
kens | Arial :-) | 15:57.15 |
chrisl | Is it "declared" as a truetype in the file? | 15:57.59 |
kens | which file ? | 15:58.09 |
chrisl | The customer's job | 15:58.19 |
kens | No, its just a 'findfont', the font is not embedded | 15:58.33 |
chrisl | Oh, it's a PS file? I thought they usually dealt with PDFs | 15:59.06 |
kens | In this case its PostScript | 15:59.13 |
chrisl | Ah, well, we have no clue what "Arial" they're asking for...... | 16:00.00 |
kens | Nope, so they get whatever we provide, like I said, I've delivered the 'embed the fonts' doctrine again | 16:03.30 |
chrisl | kens: the job itself is doing odd things with the encoding...... | 16:05.40 |
kens | chrisl it sure is, and it also emits different numbers of pages for me too.... | 16:05.57 |
chrisl | kens: I'm not inclined to look at this in more detail - the PS for loading the font is messy, and I doubt there's a solution we can implement, anyway | 16:11.55 |
kens | chrisl I agree completely, they *need* to embed the fonts. | 16:12.14 |
| One thing I do notice is that the 'correct' Acrobat document has 5 pages, but the PostScript file has 7.... | 16:14.09 |
| WHich just makes me suspicous | 16:14.32 |
chrisl | Hmm, are the pages the same? | 16:14.39 |
kens | No, there are more fonts on the later pages. | 16:14.52 |
| And when I run the 'modified' file to Distiller, I get 7 pages.... | 16:15.15 |
| ah, but the PDF file only contains 5. How does that work ? | 16:15.42 |
| Oh I see, they hacked out pages 5 and 6 | 16:16.28 |
| Anyway, enough for today, goodnight all | 16:16.55 |
chrisl | night kens | 16:17.10 |
dogisfat | Are there any equivalent calls like gx_device_has_color(dev) for typed images? | 19:40.52 |
mvrhel_laptop | bbiaw | 19:42.25 |
marcosw | sebras: I'm going to reboot casper in little while (you and I are the only people who are logged on at the moment). | 22:36.27 |
sebras | marcosw: ok... | 22:56.31 |
sebras | logs out. | 22:56.34 |
| Forward 1 day (to 2013/07/02)>>> | |