| | <<<Back 1 day (to 2012/01/31) | 2012/02/01 |
| kens | chrisl ping | 08:19.04 |
| chrisl | kens: pong | 08:29.56 |
| kens | chrisl I saw from Michael's last comment on bug #692223 that he wants another commit pulled into the release, did you get that ? | 08:37.39 |
| | I believe its commit ee811255187a9367a090ce542e78c13912e92ca6 | 08:38.00 |
| | Forget that, I just saw your commit to the branch | 08:38.17 |
| chrisl | kens: yes, he e-mailed me about it - I've got it, haven't pushed it yet | 08:38.17 |
| | Oh, I have pushed it, then.... :-) | 08:38.30 |
| kens | No, different one, sorry, reading too quickly | 08:38.45 |
| chrisl | It is there "Device Link and Proof Profile fix" | 08:39.27 |
| kens | Yeah, but I think its the black one he wants added ? | 08:39.46 |
| | No, maybe I was right the first time | 08:40.10 |
| | Yes, that is the right one. | 08:40.24 |
| | AH, they are *both* in your commit :-) | 08:40.40 |
| chrisl | As long we're up to date! | 08:41.43 |
| kens | Yes, looks fine to me, thanks | 08:41.54 |
| chrisl | kens: it looks like our (a)widthshow has always been wrong for composite fonts..... | 08:43.32 |
| kens | Even in PostScript ? | 08:44.24 |
| chrisl | Yes. It just checks for the character being space (32), but for composite fonts, you're supposed to take the font index into account, too | 08:45.05 |
| kens | Oh dear, I guess its not a common usage, especially in PostScript where there is a different operator to use, unlike PDF | 08:45.34 |
| chrisl | One problem is, the PLRM (so far) doesn't explain what to do if the subfont is *also* a composite font....... | 08:46.20 |
| kens | Hmm.... I'd have to go and read it | 08:46.42 |
| chrisl | To be honest, I'm inclined to put in a simple fix for the current problem, and wait for concrete example before looking at a more complex one | 08:47.31 |
| kens | Probably makes sense. Nobody has complained yet :-) | 08:47.48 |
| chrisl | I'll have another read of PLRM later on, then decide. I don't want to add complexity in a bit code that gets used quite often in PDF jobs | 08:49.01 |
| kens | It looks kind of complicated. | 08:49.14 |
| | But doesn't seem to involve the base font type | 08:49.27 |
| | Just font index and character code | 08:49.38 |
| chrisl | And FMapType..... | 08:49.53 |
| kens | Ah, one reading would be to follow down to the base font (the final base font) and use 'the immediate parent' | 08:50.07 |
| | So if a descsndant is itself a composite, decode that composite and so on | 08:50.25 |
| chrisl | I reckon 99.9 per cent of cases will be covered if we just make sure that the font index is 0 and ccode is 32 before applying the extra space...... | 08:51.19 |
| kens | Yes. But I do think that if you want to be entirely sure, teh above is correct. | 08:51.41 |
| | The words 'immediate parent' suggest the possibility of muptiple parents | 08:51.59 |
| | multiple | 08:52.05 |
| chrisl | I wonder if descendant fonts have a "back pointer" to their parent...... | 08:52.46 |
| kens | I would be surprised to see a use of (a)widthshow in conjunction witha a composite font which has composite descendants | 08:52.53 |
| | Not sure about back pointers. I suspect there may be something like that for the benefit of pdfwrite though | 08:53.30 |
| chrisl | Well, it can't happen in PDF, and clearly these are rarely used operators in PS! | 08:53.47 |
| kens | Well composite fonts with composite descendants are rare in PS, use of (a)widthshow is fairly rare, and its use with composite fonts very rare. Put it all together.... | 08:54.28 |
| chrisl | I will have a proper look later on, most of the information is readily available, so it maybe possible to do it properly without adding too much code | 08:56.48 |
| kens | Hmm, firefox wants an update, I wonder if java will work afterwards... | 09:12.06 |
| Robin_Watts | Morning tor8. | 10:43.03 |
| tor8 | morning Robin_Watts | 10:43.20 |
| Robin_Watts | I was going to look at 692829 and 692830 today - unless you want to lay claim to them first. | 10:43.52 |
| tor8 | Robin_Watts: go ahead. there's another mail in support with a related report about the list of operators not being sorted properly. | 10:45.12 |
| Robin_Watts | Yes. I'll look at that afterwards. | 10:45.32 |
| tor8 | great | 10:46.05 |
| Robin_Watts | Did you see the fix I pushed last night? | 10:46.18 |
| | I tweaked pdf_decode_cmap to have another arg. | 10:46.57 |
| | I'm wondering if I should have fixed it a different way. | 10:47.08 |
| | I should perhaps have made that function just return the number of bytes to advance. | 10:47.23 |
| | Then the caller could do w = pdf_decode_cmap(encoding, buf, &cpt); buf += w; | 10:48.02 |
| | and not needed another arg. I think that might be neater. | 10:48.11 |
| tor8 | you mean return the number of bytes to advance instead of the pointer? | 10:49.44 |
| Robin_Watts | Yes. | 10:49.48 |
| tor8 | you could calculate the diff in the caller :) | 10:49.51 |
| | but yes, i agree that's preferable (return w) to adding another argument | 10:50.08 |
| Robin_Watts | I could, but that feels like I'm having to 'undo' work that's already been done | 10:50.15 |
| | Will put that through today too then. | 10:50.25 |
| tor8 | yeah, so do go with the return w approach | 10:50.43 |
| Robin_Watts | tor8: ping | 13:25.58 |
| | If look at the gs-regression mails for the last few mupdf commits, you'll see that there are differences showing, when I really wouldn't have expected to see differences. | 13:26.33 |
| | Like the pdf_decode_cmap fix commit. | 13:26.43 |
| | And macpro is involved in all of them. | 13:27.48 |
| kens | I was wondering what those diffs implied. | 13:27.50 |
| Robin_Watts | So something on the macpro is working differently. | 13:28.29 |
| | Let me try windows vs macosx here. | 13:29.04 |
| tor8 | could be floating point rounding, but I think I've forced all floating point math to be single precision | 13:31.58 |
| | order of evaluation between compilers maybe? | 13:32.13 |
| Robin_Watts | windows and mac agree for me. | 13:34.20 |
| | Let me try on peeves (64bit linux) | 13:34.29 |
| | tor8: I'm tempted to take some time to clean up the jbig2dec signed/unsigned warnings I get while building mupdf on windows. | 13:36.10 |
| tor8 | Robin_Watts: can you fix the horrible gnu-snake-indentation style and mixed tabs/spaces while you're at it? | 13:36.49 |
| Robin_Watts | That sounds like a job for scripty indenty git man to me. | 13:38.40 |
| | (That's you, by the way) | 13:38.51 |
| | but we shouldn't do it without checking with shelly first. | 13:39.47 |
| | If he has local changes to his copy we don't want to drop him into merge hell. | 13:40.09 |
| chrisl | It's not even consistent....... :-( | 13:40.24 |
| | Robin_Watts, tor8: we should probably increment the jbig2dec version number, too | 13:41.06 |
| tor8 | I can certainly script up and fix the indentation, but I don't want to land anyone in merge hell | 13:41.16 |
| chrisl | shall I punt a mail off to Shelly? | 13:41.37 |
| tor8 | and clean up the makefiles and build scripts and make sure the gs/jbig2dec and jbig2dec git are completely in sync | 13:41.41 |
| | their build systems are not, but the source is | 13:41.54 |
| chrisl | I'd guess that Ghostscript doesn't use the jbig2dec build | 13:42.41 |
| Robin_Watts | tor8: It sounds like a worthwhile job, but probably doesn't want to be put on the critical path for the mupdf release. | 13:42.53 |
| tor8 | no, it's one of those "good for a lazy procrastinating afternoon" projects | 13:43.14 |
| chrisl | tor8: did we make the jbig2dec repos the canonical one, or are we still in limbo? | 13:44.01 |
| Robin_Watts | I fear I need to wait until I can get a log in on the macpro before I can look into these diffs. | 13:44.19 |
| tor8 | we're still in limbo, but they are mostly in sync now modulo the makefiles and autoconf stuff | 13:44.24 |
| | chrisl: you're the autoconf guy around here; should we really be checking in the configure script in the repo? | 13:44.55 |
| chrisl | Hmmm, interesting question: it depends, we should not in the canonical source repos, we should when it is imported from elsewhere | 13:46.17 |
| tor8 | with that definition, the jbig2dec.git is the canonical version! :) | 13:47.09 |
| chrisl | tor8: Yes, I know. The problem was that the gs one had fixes that weren't in the jbig2dec.git, so things got confused..... | 13:48.20 |
| tor8 | chrisl: fortunately porting commits between the two is fairly easy, but the build scripts I don't know enough about | 13:49.18 |
| | we should probably scrap the SConstruct and Jamfiles in jbig2dec.git | 13:49.33 |
| chrisl | IIRC, the jam build doesn't work any more, anyway | 13:49.55 |
| tor8 | quite probably. I also think I have a plain makefile that should compile a static library with no autoconfige stuff needed (or maybe that was just in a local repo) | 13:50.38 |
| Robin_Watts | tor8: Bug 692821 - I can have a crack at fixing that (just install memento.h with fitz.h) | 13:51.19 |
| chrisl | tor8: I'll make a note to rationalise the jbig2dec build differences after I'm through with the 9.05 release. | 13:51.43 |
| tor8 | Robin_Watts: yeah. make sure you catch the new header files too (muxps.h and mucbz.h). | 13:51.58 |
| | Robin_Watts: do distro maintainers frown on polluting the include directory namespace or should we put them all under a common subdirectory? | 13:52.31 |
| Robin_Watts | no idea. | 13:53.20 |
| tor8 | let's pollute then :) | 13:54.04 |
| | chrisl, do you have any ideas or opinions? | 13:54.20 |
| chrisl | I'd prefer them in a subdirectory, but I don't know what the distro's policies actually state | 13:55.24 |
| Robin_Watts | I don't see any Makefile stuff to make the cbz app. | 13:55.41 |
| chrisl | tor8: maybe ask tkamppeter for guidance? | 13:55.53 |
| tor8 | Robin_Watts: cbz is only in the pdfapp.c based viewers | 13:56.21 |
| | and ios | 13:56.27 |
| Robin_Watts | So there is no cbzdraw ? | 13:56.55 |
| | fair enough. | 13:57.00 |
| tor8 | nope | 13:57.00 |
| Robin_Watts | but presumably there will be when we have document and mudraw etc? | 13:57.13 |
| tor8 | figured I'd get that one for free with mudraw :) | 13:57.23 |
| Robin_Watts | ok. | 13:57.31 |
| | OK, so... shall I look at a top level document class then, or would you rather do that ? | 13:58.29 |
| tor8 | I would prefer to tackle that one myself, if you don't mind? | 13:58.54 |
| Robin_Watts | No, it's your baby, I completely understand. | 13:59.07 |
| | So looking back at the joblist... | 13:59.43 |
| tor8 | is parsing fz_link from xps done? | 14:00.57 |
| Robin_Watts | 1) New thirdparty.zip - DONE | 14:02.30 |
| | 2) renaming - DONE | 14:02.32 |
| | 3) docs | 14:02.34 |
| | 4) API fixes, doc interface/superclass | 14:02.36 |
| | 5) fz_link loading from XPS | 14:02.38 |
| | 6) forward port the new fz_text_device data_structures (still no idea what this means) | 14:02.39 |
| | 7) port various ghostxps fixs back to muxps - DONE | 14:02.41 |
| | 5 hasn't been looked at, no. | 14:02.51 |
| tor8 | I'm doing 6 today | 14:03.00 |
| Robin_Watts | So it looks like I should look at 5. | 14:03.14 |
| | which will be interesting as it's my first foray into the wonder wierd world of XPS. | 14:03.30 |
| | s/wonder/wonderfully/ | 14:03.45 |
| | sebras: How is 3 going? | 14:04.02 |
| tor8 | Robin_Watts: it's a nasty xml mess :) | 14:05.33 |
| Robin_Watts | lunches | 14:07.11 |
| | will face XML with a full stomach. It's better than dry retching :) | 14:07.26 |
| tor8 | Robin_Watts: http://www.ecma-international.org/publications/standards/Ecma-388.htm | 14:09.48 |
| chrisl | tor8: It's not a great advert that they feel the need to have a PDF version *and* the PDF ends up a smaller download (by a fair amount)! | 14:22.18 |
| tor8 | chrisl: well, it was convenient to have it in a readable format when writing the first version of ghostxps :) | 14:24.25 |
| | given that the metro viewer for xp at the time was broken beyond recognition | 14:24.41 |
| Robin_Watts | tor8: did you ever do a version of sane that ran xps files too ? | 15:19.36 |
| tor8 | yes, a few weeks back | 15:20.06 |
| Robin_Watts | yeah, so why isn't my version working... | 15:20.14 |
| tor8 | the one we use does xpsdraw | 15:20.20 |
| Robin_Watts | no, i have changes here. | 15:20.33 |
| | Ahem. Helps if I install some xps files to be tested :) | 15:23.05 |
| | I just created http://ghostscript.com/~robin/tiger_password.pdf for paul - tiger.eps as a pdf with the password "tiger". | 15:26.11 |
| | mupdfdraw handles it fine. Apparently the ios app doesn't. | 15:26.22 |
| | tor8: any ideas ? | 15:26.28 |
| paulgardiner | I get an error message: "Cannot open document" "missing page tree cannot open pdf document" | 15:27.27 |
| | Not a problem, provided I can find another file that does work, so that I can copy the iOS behaviour | 15:28.33 |
| tor8 | let me dig out my ipad | 15:29.06 |
| | yeah, I get the same error on my iPad too. | 15:30.39 |
| | I know I tested with some password protected files before, wonder what's gone wrong here | 15:30.53 |
| Robin_Watts | paulgardiner: Given that the file I gave you works with mupdfdraw you should be OK. | 15:31.15 |
| tor8 | Robin_Watts: well, it works with a freshly compiled ios version | 15:34.27 |
| paulgardiner | Is the PDF data actually encrypted, or is it just up to the app to refuse display until authentication? | 15:36.57 |
| Robin_Watts | paulgardiner: It's encrypted. | 15:37.21 |
| tor8 | paulgardiner: how are you testing the ios app? an ipad or using the simulator? | 15:38.51 |
| paulgardiner | Probably it's the check for whether a password is needed that's going wrong then | 15:38.58 |
| | tor8: I have the app installed on an iTouch | 15:39.20 |
| tor8 | paulgardiner: yeah, that's what it looks like. the "missing page tree" message is just a symptom of where the problem surfaces. | 15:39.33 |
| | paulgardiner: I can get you set up with a newer build if you need it | 15:40.22 |
| | Robin_Watts: how about one of the files in sane with 'password' in the name? | 15:40.53 |
| paulgardiner | I'll see how I get on with the Android app. It may work because I'm running a more up to date version. And I can probably guess the desired behaviour. | 15:42.25 |
| Robin_Watts | tor8: I was deliberately avoiding them, as they tend to have 'complex' passwords. | 15:42.37 |
| henrys_laptop | Robin_Watts you should have a login - I seem to remember ray having a problem with gdb and we had to do something or other to fix it, I'll probably remember when you trip over it and tell me the error message. | 15:43.06 |
| tor8 | yeah, it just pops up an alert/dialog with a password entry field and drops you back into the document list view if you press cancel | 15:43.08 |
| paulgardiner | Thanks. That's probably all I need to know. | 15:43.37 |
| tor8 | it just loops the dialog until you either succeed or press cancel so nothing fancy | 15:44.03 |
| henrys_laptop | Robin_Watts I guess marcosw_ found the problem so you don't need the account. | 15:47.01 |
| Robin_Watts | ah, fab. | 15:47.35 |
| | thanks. | 15:47.38 |
| | back to xps then :( | 15:47.51 |
| malc_ | tor8: hi, perhaps it's a good idea to add symlinks to prereqs archive, so that there's always a current version with a date appended? | 15:52.49 |
| Robin_Watts | malc_: Like this? http://mupdf.com/download/ | 15:54.07 |
| malc_ | Robin_Watts: yes, but where mupdf-thirdparty actually matches one of the -dated releases | 15:54.39 |
| Robin_Watts | thirdparty IS a symlink there. | 15:54.52 |
| malc_ | Robin_Watts: btw. i asked a memory question few days ago, have you seen it? | 15:54.57 |
| Robin_Watts | malc_: No, sorry, I must have missed that. | 15:55.13 |
| malc_ | Robin_Watts: grr.. right you are i missed the year part when comparing the zips.. sigh | 15:55.44 |
| Robin_Watts | (actually, for my money thirdparty.zip should point to the older one, as that's the one that goes with the released version) | 15:55.46 |
| malc_ | Robin_Watts: question was, is the memory limit supposed to be honored? | 15:56.13 |
| Robin_Watts | I replied to that. | 15:56.19 |
| | I said, "It's not a memory limit, it's the store size limit". | 15:56.35 |
| | And the store size limit should be honored, yes. | 15:56.58 |
| malc_ | Robin_Watts: must have missed the reply | 15:57.01 |
| | Robin_Watts: i've set it to 4K and still get the pages to load without seeing Xobject blah blah load failed | 15:57.26 |
| Robin_Watts | Right. Because that stuff doesn't go into the store. | 15:57.42 |
| malc_ | oh | 15:58.06 |
| Robin_Watts | If you want a hard and fast 'memory size' limit, then we don't support that currently - but you can add it yourself by putting it into the allocation functions. | 15:58.26 |
| | (i.e. it doesn't require any changes to the mupdf source) | 15:58.38 |
| malc_ | sure | 15:58.46 |
| Robin_Watts | Or if you just want it for testing, use a Memento build and then export MEMENTO_MAX=4096 before running. | 15:59.08 |
| malc_ | thanks for clarification | 15:59.09 |
| Robin_Watts | np. | 15:59.26 |
| | tor8, mvrhel: I'm failing to find any .xps files in the test suites with links in them. Maybe I'm looking in the wrong place? Do either of you know of an .xps with navigation in perchance? | 16:10.31 |
| | Actually, I bet the spec has. | 16:10.38 |
| tor8 | the spec has :) | 16:10.42 |
| | I think some of the "Handcrafted" ones may as well | 16:11.03 |
| malc_ | tor8: is there any way to get xps page dimensions without going throgh load/bound_page btw? | 16:14.18 |
| tor8 | malc_: no. the page dimensions are given in the xml of the page contents. | 16:14.43 |
| | there are supposed to be page dimensions in the fixed document xml which lists which zip entries contain which page, but none of the files we have actually do so | 16:15.29 |
| malc_ | tor8: that sucks.. | 16:15.42 |
| | then again xps sucks in general and i shouldn't care | 16:16.00 |
| Robin_Watts | Oh gawd. Each page in XPS has a list of the anchors on that page. | 16:26.08 |
| | But the only way to know whether an anchor is the whole page, or a particular element on that page is to run that page. | 16:26.29 |
| kens | Yes, that sounds like XPS | 16:26.44 |
| Robin_Watts | Kwality designs are us. | 16:26.53 |
| marcosw_ | Robin_Watts: wget isn't installed on macpro, so that's why the thirdparty.zip update failed. | 16:53.51 |
| Robin_Watts | Ah! | 16:53.59 |
| | Thanks for sorting that. | 16:54.07 |
| marcosw_ | Is there a reason the third party source isn't checked into the mupdf repository? That would make finding regressions easier as well. | 16:54.39 |
| Robin_Watts | marcosw_: That was tor8's decision. | 16:59.32 |
| kens | Goodnight folks. | 17:00.22 |
| marcosw_ | I've installed wget on the macpro and will update the third party code. | 17:00.31 |
| Robin_Watts | Thanks. | 17:00.55 |
| henrys_laptop | Robin_Watts:the common wisdom is intervals when you are stuck. | 17:01.41 |
| Robin_Watts | I'm not entirely unhappy being 'stuck' where I am. | 17:02.12 |
| henrys_laptop | yeah I'm about where I want to be going for multisport after this next marathon. | 17:03.25 |
| Robin_Watts | triathlon? | 17:03.43 |
| henrys_laptop | yes, I just did a duathlon last week - looks like I've got a lot of work to do ;-) I was much lower in the pack then a typical running race. | 17:04.49 |
| Robin_Watts | duathlon? run/bike? | 17:05.12 |
| | or swim/run ? | 17:05.17 |
| henrys_laptop | run/bike | 17:05.25 |
| Robin_Watts | How far? | 17:05.48 |
| henrys_laptop | http://www.racingunderground.com/chillycheeks/index.html | 17:06.04 |
| Robin_Watts | I intend to rebuy one of my favourite T-shirts at the staff meeting. (Old one is WAY too big now). | 17:06.29 |
| | "Alcatraz Triathlon: Dig, Run, Swim" | 17:06.38 |
| malc_ | dig? | 17:08.00 |
| henrys_laptop | i was thinking about that the alcatraz swim is shorter than ironman distance - I wonder if the issue was hypothermia without the right clothes. | 17:08.13 |
| Robin_Watts | The first part of any triathlon for me would be "drag bike out from behind shed, fix bike." | 17:08.21 |
| mvrhel | hypothermia and currents | 17:08.37 |
| Robin_Watts | henrys_laptop: The alcatraz swim is a) VERY cold, and b) strong current. | 17:08.47 |
| | mvrhel types faster :) | 17:08.54 |
| malc_ | Robin_Watts: be thankful the first part is not choosing the bikeshed color :) | 17:08.59 |
| | in a group with all the participants | 17:09.09 |
| henrys_laptop | the hardest part of the duathlon for me was finding my bike after the run. | 17:09.36 |
| | a friend of mine recommends a brightly colored towel. | 17:10.04 |
| Robin_Watts | Is he German? | 17:11.35 |
| | (That may be a joke that only the Brits will get, sorry) | 17:11.54 |
| | tor8: So... the linktarget parsing appears to already be done. | 17:13.22 |
| tor8 | yeah, we needed link targets for the outlines | 17:15.30 |
| Robin_Watts | Right. I coded it up a second time :) | 17:17.54 |
| malc_ | tor8: speaking of outlines, xpsdraw -l shows only the page numbers, is the fine postionining within a page available for xps outlines? | 17:18.29 |
| Robin_Watts | But there is obviously something I'm not understanding about the way the xml functions work, because I did a 'down' and then ran through stuff, where the existing code manages to find it by just running through 'next'. | 17:18.48 |
| | malc_: I suspect not, due to the thing I was whinging about above. | 17:19.19 |
| | (i.e. that in order to know which bit of a page the name points to, you have to run the page) | 17:19.38 |
| tor8 | Robin_Watts: which function? | 17:20.04 |
| malc_ | Robin_Watts: it's just that i added xps support yesterday and wasn't sure if it was my fault o xps's in general that outline positioning always ended at the top of the page | 17:20.09 |
| Robin_Watts | so we'd have to run through every page (or at least every page with targets on it) before we could resolve any links. | 17:20.27 |
| | xps_parse_metadata_imp | 17:20.48 |
| | My code was in the "PageContent" bit - I checked for a "PageContent.LinkTargets" and then looked in there for LinkTarget entries. | 17:21.32 |
| | but your code appears to find those LinkTarget entries by just walking through using xml_next(); | 17:21.57 |
| tor8 | Robin_Watts: ah, that one's a bit "special" in how it parses by ignoring the structure ... anyway, it's recursive (see 4 lines before the end) | 17:22.07 |
| Robin_Watts | does xml_next() walk through all the children too ? | 17:22.13 |
| | Ah! | 17:22.18 |
| | The recursion explains it. | 17:22.26 |
| | Well, I'm happy to leave it as is. | 17:22.40 |
| tor8 | yeah. that metadata parsing just looks at all the nodes for the magic attributes and ignores any actual structure | 17:22.51 |
| Robin_Watts | So it's the other end of it I need to do. Look for the NavigateUri entries. | 17:22.53 |
| | malc_: No, not your fault. | 17:23.12 |
| tor8 | I'd be happy enough with the linkdests being page only for xps, since parsing the actual page when you load outlines sn't much fun. | 17:23.30 |
| Robin_Watts | tor8: I agree. | 17:23.49 |
| malc_ | Robin_Watts: funny how ECMA-388.pdf has only one outline entry "Untitled" and ECMA-388.xps has em all, but they are crippled like that (no fine positioning) | 17:23.59 |
| tor8 | I guess we could backpatch more precise positioning into the link dests once we load the page, but I doubt anyone will care enough | 17:24.05 |
| Robin_Watts | We *could* fine resolve the outline when we follow a link... what you said. | 17:24.18 |
| | tor8: Is there code in here to resolve Uri's together? | 17:32.54 |
| | (i.e. give it a base and another relative one, and get a new 'absolute' one ? | 17:33.22 |
| tor8 | yes, somewhere | 17:34.35 |
| | xps_absolute_path | 17:34.55 |
| Robin_Watts | thanks. | 17:35.04 |
| tor8 | for most parsing we prepare a "base_uri" argument that gets passed around | 17:35.42 |
| Robin_Watts | yes, I have that. | 17:35.56 |
| tor8 | then you're all set | 17:37.44 |
| Robin_Watts | tor8: Doesn't cope with things that start: "scheme://" | 17:39.58 |
| | If I find any such files, we can fix that :) | 17:40.09 |
| ray_laptop | all: I was thinking about getting rid of the extra 'fillpage' actions by relying on the graphics_type_tag being GS_UNKNOWN_TAG (then after the fillpage, we set it to GS_PATH_TAG). I need to do some clean-up on the type_tag logic for this to work. | 17:44.58 |
| | the other approach is to add a 'page_is_marked' state to the device struct (independent of the graphics_type_tag). A bit cleaner | 17:45.50 |
| | any comments ?? | 17:46.00 |
| Robin_Watts | ray_laptop: The idea being that this will eliminate us ever blanking a blank page? | 17:47.54 |
| ray_laptop | Robin_Watts: correct | 17:48.01 |
| Robin_Watts | Well, it sounds like an admirable aim. | 17:48.17 |
| ray_laptop | currently we usually do the 'fillpage' at least twice | 17:48.23 |
| Robin_Watts | The unknown tag thing sounds like a "Cunning Engineering Trick" (i.e. a hack) | 17:48.47 |
| ray_laptop | Robin_Watts: is your preference to overload the tag, or to have a separate bool ? | 17:48.57 |
| Robin_Watts | but that's not necessarily to mean it's not a good idea. | 17:49.10 |
| ray_laptop | typed too slow | 17:49.13 |
| Robin_Watts | Do we ever change the TAG back to unknown again once it's set ? | 17:49.44 |
| ray_laptop | I started out thinking that "clever" was good, but am coming around to a separate bool. | 17:50.12 |
| Robin_Watts | separate bool sounds cleaner to me. | 17:50.37 |
| ray_laptop | in either case I need to make sure that the tag gets reset to UNKNOWN or that the bool get set to false at the correct time | 17:50.54 |
| Robin_Watts | (Though, I'd assume my standard position and advocate a flags word) | 17:50.58 |
| | Will this catch documents that do explicit rectangle fills to cover the page as the first thing in the content stream? I'm guessing no. | 17:51.35 |
| ray_laptop | Robin_Watts: no, it won't catch those, but we _could_ add code to check the page_is_marked state and then if the fill is for the whole page and the color is the same, ignore it. But that requires keeping the color of the fillpage (not necessarily white) | 17:53.47 |
| Robin_Watts | ray_laptop: Right. That would be the 'gold standard' fix I think. | 17:54.13 |
| | (Probably we should only suppress those if we are painting white, right? as the buffers get cleared to white, yes?) | 17:55.19 |
| ray_laptop | We can suppress any full page paint that matches the color_index value of the fillpage | 17:56.01 |
| | The device starts out as 'page_is_marked' == true (so fillpage will know to fill) and fillpage sets it false. Subsequent fillpage _or_ full page path fills also skip painting as long as the color matches and the flag is still false. | 17:59.55 |
| Robin_Watts | OK. And devices that supply preblanked buffers can set page_is_marked to false initially ? | 18:00.54 |
| | (I'm thinking of the planar device here, where bands are passed in from the band donor. If the band donor has already blanked the bands, it would be nice not to have to redo that) | 18:02.05 |
| ray_laptop | Robin_Watts: true, but they also have to set the color to whatever they fill with so that a (file specific) background fill of a different color will work correctly | 18:02.17 |
| Robin_Watts | ray_laptop: Sure. | 18:02.32 |
| ray_laptop | Robin_Watts: does the band donor tell you whether or not the page is cleared, and with what value ? | 18:03.01 |
| Robin_Watts | ray_laptop: Currently it does not. | 18:03.55 |
| ray_laptop | Robin_Watts: yep -- I just looked at gdevplib.h | 18:04.59 |
| Robin_Watts | But when I've implemented band donors on top of the potential-customers firmware, they were clearing the buffers to 0 each time. | 18:06.18 |
| ray_laptop | Robin_Watts: if it just tells us that it is pre-filled (return code ==1, for example) then we can get the color index by looking in the buffer. code == 0 means not filled | 18:06.26 |
| Robin_Watts | or was it FF? I forget. | 18:06.32 |
| | yeah. | 18:06.35 |
| ray_laptop | oops -- it returns a pointer, not a success code (NULL is error) | 18:07.23 |
| | so we'd have to change the API for the extra info :-( | 18:07.52 |
| Robin_Watts | probably. It's something to consider if we ever get a customer that uses it. | 18:08.49 |
| ray_laptop | or add a proc to the band_donor set that we call to ask if the band we just got was filled, and with what value. The default for this says "damnifikow" (page is not filled) | 18:09.14 |
| | at least the latter is backwards compatible with the current gs_band_donor_get | 18:09.43 |
| henrys_laptop | ray_laptop:what is the source of the redundant fillpages? | 18:17.03 |
| | why is erasepage called more than once per page? | 18:17.18 |
| Robin_Watts | setting devices etc, isn't it? | 18:18.12 |
| ray_laptop | henrys: per the PS spec, 'setpagedevice' erases the page. | 18:18.16 |
| | I haven't looked (yet) at PCL to see if something makes it happen there. | 18:18.41 |
| henrys_laptop | I think I've eliminated the multiple blank pages in the pcl interpreter. | 18:19.43 |
| ray_laptop | henrys: I'll verify that with the debugger, but that would be good. But a PCL driver _could_ still do a full page fill at the start, right ? | 18:20.46 |
| henrys_laptop | no pcl and xl have dirty page heuristics. | 18:21.15 |
| | originally pcl used the bbox device for this but that was a performance burden so I switched it to conservatively setting a boolean. - for example it can mark a page dirty when the output is clipped and such. | 18:22.36 |
| | ray_laptop:you can explicitly do a form feed and erase the page but I don't think this is worth optimizing. | 18:23.56 |
| | ray_laptop:I guess I don't understand why we'd have very many extraneous setpagedevices are you sure there isn't some other unintended source like in the pdf interpreter. | 18:25.47 |
| Robin_Watts | tor8: When I identify a link_dest, I'm way down in the middle of the path/glyph/canvas parsing stuff. | 18:27.01 |
| | The PDF stuff hangs the list of link_dests off the page object - but I don't have the page object at this stage. | 18:27.27 |
| ray_laptop | henrys: with PS we get two '.fillpage' actions for tiger.eps -- for tiger.pdf we get three -- I'd rather fix it in the graphics lib than try and maintain 'page_is_marked' state at the PS / PDF interp (gs_setpd.ps) layer | 18:27.49 |
| Robin_Watts | I may need to add a 'current_page' object to doc, and set it in xps_load_page. | 18:28.12 |
| tor8 | Robin_Watts: link or link_dest? | 18:28.20 |
| Robin_Watts | That way I can have an xps_add_link_dest. | 18:28.31 |
| | link_dest I believe. | 18:28.36 |
| | No, link, sorry. | 18:29.08 |
| ray_laptop | henrys: PDF's have a background color for the page, so we have to fill with that in the PDF interp since we don't know what color the device filled with. | 18:29.56 |
| Robin_Watts | tor8: Either that or we could push the link stuff through the device interface. | 18:30.42 |
| | actually, no that scares me. | 18:30.58 |
| tor8 | Robin_Watts: we could scan through the page xml once looking specifically for links | 18:33.06 |
| | so we have them at page load time rather than when running the page for the device | 18:33.33 |
| Robin_Watts | tor8: But then we'd have to redo all the parsing- because we need to know the areas of each thing. | 18:33.34 |
| henrys_laptop | ray_laptop:I wasn't proposing you use a boolean in the interpreter just verifying the erasepages are actually necessary before "fixing" it. | 18:33.38 |
| tor8 | Robin_Watts: drats. is this for link-dests only or for the source links too? | 18:33.56 |
| Robin_Watts | The dests we get (at page granularity) at load time. | 18:34.34 |
| | The sources (i.e. where you click to go to a dest) we get only when we run the page. | 18:34.55 |
| tor8 | *sigh* | 18:35.03 |
| | that's a mess :( | 18:35.22 |
| Robin_Watts | It's not the end of the world. | 18:35.45 |
| | For PDF, it's hard to imagine how you'd want the dests BEFORE you've run the page. | 18:36.01 |
| | the sources, sorry. | 18:36.06 |
| | You run the page to display it, then people can click on the page to go somewhere else. | 18:36.23 |
| tor8 | well, there is the caveat of when to load links then. but we could force a run with the null device if the links are requested before we've run the page. | 18:36.48 |
| Robin_Watts | So a page not having the list of links available until it's been rendered doesn't seem like the end of the world to me. | 18:37.07 |
| | We could do that, yes. | 18:37.10 |
| henrys_laptop | ray_laptop:if you do it in the graphics library I'll likely take out the dirty page cod from pcl. | 18:37.11 |
| | s/cod/code | 18:37.21 |
| ray_laptop | henrys: OK. I'm looking at this for cust 532, but want to do it the same way as I do in the HEAD (post 9.05). | 18:47.01 |
| | but now I have to figure out what's up with the latest profile from them | 18:48.28 |
| mvrhel | bbiaw | 18:50.58 |
| Robin_Watts | tor8: First attempt in my repo on casper. Seems to work. Got to run. | 19:51.28 |
| sebras | tor8 Robin_Watts: tor8 okayed the general look of sebras/doc some time ago, I'll assume this is inline with expectation and will forge ahead... | 22:00.06 |
| Agiofws | hello | 22:52.48 |
| | does anyone know how to set up | 22:52.55 |
| | a panasonic dp-8016p ? | 22:53.11 |
| | iin linux ? | 22:53.18 |
| | does it atleast work in linux ? | 22:53.31 |
| sebras | Agiofws: I have no idea, but I found this by googling: http://forums.gentoo.org/viewtopic-t-751814.html | 22:55.24 |
| | Agiofws: so it seems as if someone got it at least partly working. | 22:55.56 |
| Agiofws | sebras, thats for usb connection right ? | 22:57.19 |
| | i'm on it via ethernet | 22:57.31 |
| | localhost - - [02/Feb/2012:00:57:01 +0200] "POST /printers/Panasonic_DP-8016P_192.168.3.15 HTTP/1.1" 200 504 Print-Job successful-ok | 22:57.57 |
| | ^^ | 22:57.57 |
| | but printer just won't move | 22:58.03 |
| sebras | Agiofws: I think so, but your googling is as good as mine. :) | 22:58.24 |
| Agiofws | ya but knowledge ... is different | 22:58.48 |
| sebras | Agiofws: not really, I have never seen the printer. | 23:00.57 |
| Agiofws | it says success but printer won'ty move at all | 23:02.40 |
| henrys_laptop | Agiofws how are you sending the job? lpr, ftp?? | 23:03.36 |
| Agiofws | through open office through cups through lp aswell | 23:04.20 |
| henrys_laptop | what are you sending through lp? hopefully not the application file. | 23:06.04 |
| Agiofws | a text file | 23:07.13 |
| | lp -d Panasonic_DP-8016P_192.168.3.15 Zar-Er.txt | 23:07.28 |
| | request id is Panasonic_DP-8016P_192.168.3.15-67 (1 file(s)) | 23:07.32 |
| henrys_laptop | nothing in /var/log/cups/error_log? | 23:07.58 |
| Agiofws | "POST /printers/Panasonic_DP-8016P_192.168.3.15 HTTP/1.1" 200 108002 Send-Document successful-ok | 23:08.20 |
| | no | 23:08.22 |
| | thats the error log | 23:08.27 |
| henrys_laptop | ftp directly to the ip address and "put" the file. | 23:08.31 |
| Agiofws | how | 23:08.36 |
| | oh | 23:08.41 |
| henrys_laptop | no data light on the printer when you send the file? | 23:09.41 |
| Agiofws | its asking me for a name | 23:09.47 |
| | Name (192.168.3.15:agiofws): ? | 23:09.56 |
| henrys_laptop | try anonymous | 23:10.12 |
| Agiofws | 530 access denied. | 23:10.15 |
| | Login failed. | 23:10.15 |
| henrys_laptop | you'd have to look at your printer docs for that. Does the data light blink when you send data through lp | 23:11.02 |
| | ? | 23:11.03 |
| Agiofws | the light on the ethernet connector ? | 23:11.31 |
| henrys_laptop | there should be something on the printer no? | 23:11.47 |
| Agiofws | ame (192.168.3.15:agiofws): anonymous | 23:11.53 |
| | 331 Password required. | 23:11.53 |
| | Password: | 23:11.57 |
| | 530 access denied. | 23:11.57 |
| | works through windows client | 23:12.16 |
| henrys_laptop | there should be a data light on the printer that will blink when you send the job. | 23:13.31 |
| Agiofws | localhost - - [02/Feb/2012:01:13:58 +0200] "POST /printers/Panasonic_DP-8016P_192.168.3.15 HTTP/1.1" 200 377 Create-Job successful-ok | 23:14.23 |
| | localhost - - [02/Feb/2012:01:13:58 +0200] "POST /printers/Panasonic_DP-8016P_192.168.3.15 HTTP/1.1" 200 294 Send-Document successful-ok | 23:14.27 |
| | it says online | 23:14.27 |
| | ftp> put hello.txt | 23:15.12 |
| | local: hello.txt remote: hello.txt | 23:15.13 |
| sebras | Agiofws henrys_laptop: ftp://ftp.panasonic.com/pub/panasonic/business/office/brochures/DP-8016P_brochure.pdf on page 4 Panasonic states that their printer works in Unix/Linux if you have an "optional printer controller module". | 23:15.13 |
| Agiofws | 530 access denied. | 23:15.17 |
| | ftp: bind: Address already in use | 23:15.17 |
| henrys_laptop | according to the documentation it says Panasonic Printing System for Windows for the language | 23:15.34 |
| | sebras right that gives you pcl then you can use ghostscript | 23:15.56 |
| sebras | henrys_laptop: so panasonic are using their own language instead of PCL, rendering printing in linux impossible unless a printer controller module is connected to the printer? | 23:17.18 |
| Agiofws | what is a printer controller module ? | 23:18.02 |
| | so its easy to get this working in linux ? | 23:18.30 |
| sebras | Agiofws: according to the brochure I linked to you will only be able to use cups properly if your printer has this optional controller module. | 23:19.24 |
| henrys_laptop | sebras:yes the documentation says PCL is optional. I don't know if it is there own language or some breed of gdi. | 23:19.34 |
| Agiofws | optional controller module so its hardware ? | 23:19.58 |
| | i HATE BREEDS I hate it when people don't establish comaptible standards ... | 23:20.34 |
| | i hate it when it only works under windows | 23:20.44 |
| | anything i could try ? | 23:21.00 |
| sebras | Agiofws: try looking in the documentation for printer controller module. | 23:21.29 |
| | Agiofws: my best bet is that you need this to get it working (from linux). | 23:21.47 |
| Agiofws | i don;t have the manuals | 23:22.05 |
| sebras | Agiofws: but yes, it should be hardware. | 23:22.46 |
| Agiofws | ok thanks | 23:24.15 |
| | you think a newer version of cups would fix this ? | 23:25.08 |
| henrys_laptop | Agiofws do you have a simple pdf file? | 23:26.28 |
| sebras | Agiofws: http://goo.gl/gLdKv here you can find model name of the module, should you want to try to order it. | 23:27.47 |
| henrys_laptop | I doubt this will work but you can try it: gs -sDEVICE=gdi -o "|lp" myfile.pdf | 23:28.33 |
| Agiofws | ok | 23:29.49 |
| | GPL Ghostscript 8.71 (2010-02-10) | 23:32.00 |
| | Copyright (C) 2010 Artifex Software, Inc. All rights reserved. | 23:32.02 |
| | This software comes with NO WARRANTY: see the file PUBLIC for details. | 23:32.07 |
| | Processing pages 1 through 1. | 23:32.07 |
| | Page 1 | 23:32.07 |
| | gs -sPanasonic_DP-8016P_192.168.3.15=gdi -o "|lp" dilosisimetoxis.pdf ? | 23:32.52 |
| henrys_laptop | no literally -sDEVICE=gdi | 23:35.39 |
| Agiofws | kk | 23:36.34 |
| | lp: Error - no default destination available. | 23:37.13 |
| henrys_laptop | sorry -o "|lp -d Panasonic_DP-8016P_192.168.3.15" | 23:38.54 |
| Agiofws | gs -sDEVICE=gdi -o "|lp -d Panasonic_DP-8016P_192.168.3.15" dilosisimetoxis.pdf ? | 23:39.42 |
| sebras | Agiofws: yes. | 23:39.53 |
| henrys_laptop | yes | 23:39.53 |
| Agiofws | Page 1 | 23:39.56 |
| | request id is Panasonic_DP-8016P_192.168.3.15-72 (0 file(s)) | 23:39.57 |
| | ? | 23:40.02 |
| henrys_laptop | sebras how are the docs? | 23:40.03 |
| sebras | henrys_laptop: being written. :) | 23:40.53 |
| Agiofws | ok | 23:41.41 |
| | thank you | 23:41.45 |
| | it seems its just not comaptible | 23:41.53 |
| | compatible | 23:41.59 |
| henrys_laptop | Agiofws:so you send that the printer light should blink a bit and then it should either print or not. If not it didn't work. | 23:42.00 |
| Agiofws | ok | 23:42.10 |
| | wait let me see | 23:42.15 |
| sebras | henrys_laptop: tor8 and I agreed on a header doc format, hopefully Robin_Watts thinks it's acceptable too. | 23:43.04 |
| henrys_laptop | sebras:great | 23:45.52 |
| sebras | henrys_laptop: some of my questions have resulted in some changes to the "public" mupdf interface. | 23:47.08 |
| | to make mupdf easier to use for clients. | 23:48.03 |
| Agiofws | henrys, when i use the lpr command | 23:51.15 |
| henrys_laptop | sebras I sort of expected that - usually when writing about an API or implementation it gets changed. | 23:51.19 |
| Agiofws | the lp command | 23:51.22 |
| | the ethernet .... light blinks | 23:51.39 |
| | but printer won't move | 23:52.05 |
| henrys_laptop | but does it print ;-)? | 23:52.27 |
| | there's no light on the printer? | 23:52.35 |
| Agiofws | nope | 23:52.43 |
| | there are lights on it | 23:52.56 |
| | there are many lights | 23:53.04 |
| | there is a printer online light | 23:53.15 |
| | there is a print button light | 23:53.22 |
| | ok | 23:53.31 |
| henrys_laptop | most printers have a "data" light that will blink as you send data. | 23:53.42 |
| Agiofws | no | 23:53.51 |
| henrys_laptop | or at least come on once. | 23:53.54 |
| Agiofws | no light blinks on the surface of the printer | 23:54.08 |
| | only the light of the etherenet connector | 23:54.17 |
| henrys_laptop | I guess your stuck contacting the printing company if you want linux printing. | 23:54.35 |
| | if you do tell them you recommend they support linux out of the box. | 23:55.15 |
| Agiofws | heh | 23:55.58 |
| | people here are so windows oriented that they'll look at you like they've seen a UFO | 23:56.32 |
| | how can you talk to a technician when he doesn't even know what cups is ? | 23:57.05 |
| | anyway thank you guys | 23:57.25 |
| | most helpfull | 23:57.32 |
| | have you been | 23:57.37 |
| | obi wan | 23:57.41 |
| henrys_laptop | sure sorry we couldn't help more | 23:57.47 |
| | Forward 1 day (to 2012/02/02)>>> | |
IRC Logs