| | <<<Back 1 day (to 2012/04/19) | 2012/04/20 |
| mvrhel | ugh devn_put_params is not correct | 00:11.50 |
| | this thing is a mess | 00:33.51 |
| | dinner time. | 00:34.03 |
| | ugh. marcosw. ran into a somewhat serious issue when processing ps files (not pdf) in the new planar sep approach. | 06:07.38 |
| | in this case, it is not known how many spot colors appear on the page when you start rendering the page | 06:08.05 |
| | makes life difficult in allocating the proper sized buffer | 06:08.16 |
| | need to talk to ray_laptop about this tomorrow | 06:08.40 |
| | good night | 06:13.15 |
| kens | Hi tor8, still waking up early ? | 07:56.07 |
| tor8 | kens: yeah... traveling west does that. | 07:56.38 |
| kens | THought you might be over it by now. At least the next staff meeting will be easier for you | 07:57.08 |
| tor8 | kens: I have been hitting the sack earlier than usual :) | 07:57.37 |
| | hopefully I can keep it up until the next meeting... | 07:57.55 |
| kens | :-) | 07:58.06 |
| | less than 2 weeks now | 07:58.16 |
| | Hmm, my hiny new release code for patterns didn't get called :-( I wonder why.... | 07:59.26 |
| Robin_Watts | Morning all. | 09:13.10 |
| kens | Morning Robin_Watts | 09:13.17 |
| Robin_Watts | tor8: Shall we try to get 1.0 out today? | 09:13.18 |
| paulgardiner | Hi Robin | 09:13.20 |
| | And hi Tor | 09:13.38 |
| kens | thinks 1.0 is a myth | 09:13.38 |
| tor8 | morning robin, paul | 09:13.50 |
| paulgardiner | And hi ken :-) | 09:13.50 |
| sebras | Robin_Watts: anything left on my agenda? | 09:13.51 |
| Robin_Watts | paulgardiner: I checked with tor8 and the disabling of internal link following on android was deliberate to make it match ios. | 09:13.56 |
| kens | Morning paulgardiner | 09:13.58 |
| Robin_Watts | sebras: I am not aware of anything blocking 1.0 now - if anyone else knows, speak now... | 09:14.20 |
| paulgardiner | Robin_Watts: oh ok good. | 09:14.23 |
| sebras | Robin_Watts: sounds good. | 09:14.40 |
| paulgardiner | sebras: morning | 09:14.46 |
| sebras | paulgardiner: good morning! | 09:14.55 |
| Bo98 | Hello paulgardiner, Robin_Watts told me to ask you how I would use MuPDF in my existing Eclipse Android project. Is it as simple as copying the files from the android directory in MuPDF? | 09:26.58 |
| Robin_Watts | paulgardiner: I know you used Eclipse, at least for a while... | 09:28.12 |
| | Are you still using it? If so, is there an eclipse project that would be sensible for us to include in 1.0 ? | 09:28.48 |
| paulgardiner | Yes, throughout in fact. I'm trying to remember exactly what I did. I remember it was simple. | 09:28.49 |
| Robin_Watts | (or if it's trivial to make, we could update the android/ReadMe.txt to say how) | 09:29.22 |
| paulgardiner | I "operned" the project in Eclipse rather than adding what was there to an existing eclipse project. | 09:29.49 |
| | "opened" that was supposed to be. | 09:30.22 |
| Bo98 | Okay there isn't anyway to take it into an existing project? | 09:30.34 |
| paulgardiner | There may well be. It may be very simple. I'd imagine it was, but I haven't done so myself. | 09:31.48 |
| Bo98 | Ok. | 09:32.20 |
| paulgardiner | I wasn't able to get Eclipse to do the native part of the build. | 09:32.27 |
| Bo98 | Hmm, I don't actually see the Eclipse project in the android folder. | 09:32.39 |
| | Just the files | 09:32.53 |
| Robin_Watts | Bo98: The eclipse project is not included currently. | 09:33.12 |
| paulgardiner | I never committed the project to the repo because Eclipse was able to open the project just based on the files that were there. | 09:33.21 |
| Bo98 | Ok I understand now. | 09:33.37 |
| paulgardiner | It will create the rest on the fly. | 09:33.49 |
| | I'm afraid I don't remember exactly what I did: "new project" "open file". Not sure. As Robin said the README should be updated, so I ought to work out what I did. | 09:35.20 |
| Bo98 | Okay, and it calls MuPDF files outside the android directory right? | 09:35.57 |
| paulgardiner | Yes. | 09:36.42 |
| | But only in the native part of the build | 09:37.03 |
| | I used Eclipse only for the Java part | 09:37.22 |
| | The makefiles in mupdf/android/jni tell it where the library files are. | 09:38.42 |
| Bo98 | Okay, I'll have a little play around and report back in a few hours (I have to go out for a bit now). | 09:39.23 |
| paulgardiner | Ok. Catch you later. | 09:39.43 |
| naveen_ | Hi Robin,Morning.. | 09:40.16 |
| Robin_Watts | Morning | 09:40.57 |
| naveen_ | I have tried to implement read_decrypt_file function....You can have a look at it here...http://pastebin.com/CCLAAR08 | 09:42.15 |
| | I'm using a struct rimage_aesd_s as suggested by you....How can I get this reference from fz_stream? | 09:43.16 |
| Robin_Watts | rimage_aesd *aesd = (rimage_aesd *)stm->state; | 09:44.30 |
| | seek_decrypt_file looks wrong to me. | 09:45.35 |
| naveen_ | I'm relying on stm->pos for the position of the fileHandler... | 09:46.11 |
| | when read is called again..i'll decrypt the correct block and send the data... | 09:46.38 |
| | I'm relying on stm->pos to get the block number... | 09:47.10 |
| Robin_Watts | So the sole purpose of still calling lseek is to clamp n to a valid value ? | 09:47.40 |
| naveen_ | yes... | 09:48.26 |
| | *(int*)stm->state is being used for fileHandler in read function...Can I set state reference to rimage_aesd_s ang get its reference by saying rimage_aesd *aesd = (rimage_aesd *)stm->state; | 09:49.53 |
| Robin_Watts | In the existing code stm->state is being used as an int for the filehandle. | 09:51.35 |
| | You will be using stm->state as a pointer to your rimage_aesd_s structure. | 09:51.57 |
| | So you'll need to have an int filehandle; in that structure. | 09:52.09 |
| naveen_ | ok..got that... | 09:52.34 |
| Robin_Watts | and then everywhere the code currently uses *(int *)stm->state; you'll use aesd->filehandle | 09:53.06 |
| naveen_ | in stm_open.c function only right? | 09:53.31 |
| | sorry file* | 09:53.38 |
| Robin_Watts | Within read_file/seek_file/close_file. | 09:53.53 |
| | read_encrypted_file/seek_encrypted_file/close_encrypted_file I mean, sorry. | 09:54.13 |
| naveen_ | yaa...and does read_encrypted_file function look correct? | 09:55.21 |
| Robin_Watts | You'll also need something like: http://pastebin.com/xbCQ9zXS | 09:56.13 |
| | I can't instantly spot a flaw in it. | 09:56.43 |
| naveen_ | ok..then I'll try with this and let you know the update.. | 09:57.21 |
| | to test this I need to use the nadroid app right? | 09:57.40 |
| Robin_Watts | I'd test it on windows, personally. | 09:58.05 |
| | Pick the platform you're most comfortable with. | 09:58.17 |
| | Debugging native code on android is a bit of a bitch, IME. | 09:58.31 |
| | so getting it working under a platform with a decent debugger seems sensible to me. | 09:58.57 |
| naveen_ | hmm...I'm not sure how to debug on windows....i.e how to call fz_open_encrypted_file ? | 09:59.53 |
| Robin_Watts | naveen_: Do you have Visual Studio? | 10:00.08 |
| naveen_ | yes | 10:00.11 |
| Robin_Watts | OK, so open win32/mupdf.sln in visual studio. | 10:00.34 |
| naveen_ | yup,I did | 10:00.45 |
| Robin_Watts | That has various different projects in it, including mupdf (the simple windows viewer) and mudraw (the command line drawing tool) | 10:01.07 |
| | Personally, I tend to work with mudraw rather than mupdf, but either would be fine. | 10:01.31 |
| | Let's use mudraw for simplicity. | 10:01.58 |
| | If you look, there is a mudraw.c file - that's the top level file that makes calls into the mupdf lib. | 10:02.24 |
| naveen_ | yes | 10:02.55 |
| Robin_Watts | Actually... ignore that, sorry. | 10:03.36 |
| | Look at pdf_xref.c in the pdf_open_document function. | 10:03.50 |
| | You'll see there there is a fz_open_file call? Change that to fz_open_encrypted_file | 10:04.12 |
| | Then mudraw will open your file with encryption. | 10:04.28 |
| | Assuming you use a debug build, then: | 10:04.54 |
| | win32\debug\mupdf.exe -o out.png -d encrypted.pdf | 10:05.17 |
| | will render encrypted.pdf and output it as out.png | 10:05.33 |
| | OK? | 10:05.44 |
| naveen_ | ok...will try that... | 10:06.09 |
| Robin_Watts | tor8: ping? | 10:28.58 |
| tor8 | pong. | 10:33.39 |
| Robin_Watts | Is there anything I can be doing to help get 1.0 out the door? | 10:34.21 |
| | I could update the pdf_version to return 1.0 and push to my repo on casper, and do builds etc from that. If that all tests out OK, we can push and tag that. | 10:35.54 |
| tor8 | I build on VS2008; is there a benefit to building on 2005? | 10:37.01 |
| | with 2010 we can't run the result on win 2000, but I think 2008 is safe | 10:37.28 |
| Robin_Watts | That's my memory too. | 10:37.41 |
| | Building on VS2008 sounds fine to me. | 10:37.53 |
| | Someone suggested we should run the windows binaries through upx, as that makes them a lot smaller. | 10:38.10 |
| tor8 | oh, right, there was one thing that bothers me ... all the pdfclean & show tools duplicating 5mb of font and cmap data. the download become a lot heavier than it needs to be. | 10:38.21 |
| Robin_Watts | Right, but with the fz_document stuff, I don't see how we can avoid that. | 10:38.38 |
| | Oh, I noticed this morning that pdfapp doesn't use fz_document_open | 10:38.52 |
| tor8 | I've had bad luck stripping windows mupdf binaries in the past. might've been user error, but IIRC the embedded font data was corrupted | 10:39.03 |
| | Robin_Watts: yeah, the windows UCS2 / UTF-8 filename madness thing prevented that. | 10:39.27 |
| Robin_Watts | ok. | 10:39.32 |
| | What did you use to strip before? | 10:39.40 |
| tor8 | we should probably add a fz_open_document_with_stream call before 1.0 | 10:39.42 |
| | strip.exe from msys I think | 10:39.52 |
| vtorri | UTF-8 ? i thought that on Windows, it was UTF-16 | 10:39.52 |
| | /s/was/is | 10:40.02 |
| Robin_Watts | I'll add an fz_document_with_stream then, unless you want to? | 10:40.23 |
| tor8 | vtorri: exactly. _wopen takes UCS2 and we don't do the "right" thing in the windows app | 10:40.26 |
| vtorri | tbh, forget about MinGW.org and use mingw-w64 toolchain to compile mupdf | 10:40.49 |
| tor8 | Robin_Watts: we could work around that issue by stating that fz_open_file takes a utf-8 filename and inside that do an #ifdef _WIN32 and convert from utf-8 to ucs2 and open with _wopen. | 10:40.57 |
| vtorri | and you'll have 32 and 64 bits support | 10:41.01 |
| tor8 | vtorri: I use msys from msys-git, but the mupdf builds on windows use VS2008 | 10:41.27 |
| vtorri | ok | 10:41.41 |
| | i use mingw-w64 myself | 10:42.03 |
| tor8 | Robin_Watts: I think that would be a good idea before 1.0 actually (pass filenames as utf-8 always) | 10:42.03 |
| Robin_Watts | I'm not sure. | 10:42.12 |
| tor8 | the win32 app would then convert its command line arguments from UCS2 into UTF-8 and then it gets converted back when we open the file. | 10:42.53 |
| | it would remove the need for fz_open_fd | 10:43.12 |
| Robin_Watts | Why open/close rather than fopen/fclose ? | 10:43.21 |
| | Been meaning to ask that for years. | 10:43.33 |
| tor8 | Robin_Watts: because our filters layer does its own buffering | 10:43.49 |
| | and buffering twice is a lot of extra pointless memcpy:ing | 10:44.07 |
| vtorri | http://trac.enlightenment.org/e/browser/trunk/evil/src/lib/evil_util.c#L81 <--- if you want to UTF-16 to UTF-8 conversion | 10:44.17 |
| | i've written it | 10:44.25 |
| | the reverse transformation is the almost same | 10:44.37 |
| | is almost the same* | 10:44.43 |
| Robin_Watts | mupdf contains such things already, but thank you. | 10:45.02 |
| vtorri | ho, ok | 10:45.15 |
| Robin_Watts | tor8: How about mudraw - how would that work on windows? | 10:46.58 |
| | And fz_open_document_with_stream gets us back to the 'how to we know what content type' problem ? | 10:47.49 |
| tor8 | Robin_Watts: hmm. good question. | 10:47.57 |
| Robin_Watts | No extension to check. | 10:47.58 |
| | I think we should leave it as is. | 10:48.05 |
| tor8 | yeah, that's why I haven't implemented it yet. | 10:48.08 |
| | we could pass a filename or magic string as a separate argument for the open_with_stream. ugly and hacky though. | 10:48.47 |
| Robin_Watts | I'd rather leave the existing interface, cos it's clean. | 10:48.59 |
| | We can add format recognisers post 1.0. | 10:49.08 |
| tor8 | in win_main.c at the moment, we open the file with _wopen, convert the filename to utf-8 for the window title and pdfapp_open's duplication of the filetype detection | 10:50.26 |
| | I'd be happier to pass the utf-8 filename directly and then just use fz_open_document in pdfapp | 10:50.43 |
| Robin_Watts | tor8: Actually, reload gets that wrong :( | 10:52.23 |
| | oh, no it doesn't. | 10:53.16 |
| tor8 | it's a mess with a global variable | 10:53.24 |
| Robin_Watts | tor8: So, do you want to tackle that? | 10:55.09 |
| | sebras: bug 692685. | 10:55.21 |
| | If I render at 600dpi, I see the dots. | 10:55.29 |
| | I think basically we honour their size, where acrobat 'boosts' them. | 10:55.44 |
| tor8 | Robin_Watts: I'll clean that up, yes. | 10:56.08 |
| Robin_Watts | chrisl: Are you here? | 11:01.22 |
| chrisl | Robin_Watts: yes | 11:07.09 |
| Robin_Watts | chrisl: for when you return; bug 692943: you said that gs copes because it just drops back to using the droidsans fallback font for cidfonts, rather than mupdf which uses our arial equivalent. I coded that up the other day for mupdf and found it worked for that file. | 11:07.19 |
| | Tor did some more tests though, and found it failed for any non 7 bit ascii chars. | 11:07.33 |
| | Does gs also fail for such chars? | 11:07.49 |
| chrisl | Yes | 11:07.54 |
| Robin_Watts | OK, thanks. | 11:08.16 |
| sebras | Robin_Watts: alright, I'll mail fabrice who mailed me. | 11:08.39 |
| chrisl | The thing is, the way GS works now is what "people" wanted (apparently) | 11:08.52 |
| kens | Presumably Acrobat works/fails the same way | 11:09.40 |
| | Which is always what people want | 11:09.51 |
| | lunch, back soon | 11:10.01 |
| Robin_Watts | I am tempted to believe that having something that works for 7bit ascii is better than not having something that works at all. | 11:10.03 |
| chrisl | I haven't tested Acrobat without Arial there | 11:10.06 |
| kens | Could change font name to something Silly 'eg Orial' | 11:10.34 |
| chrisl | I take it MuPDF doesn't have anything like GS's cidfmap mapping? | 11:10.57 |
| Robin_Watts | No. | 11:12.33 |
| chrisl | So, MuPDF has no way to access the "system" fonts | 11:12.59 |
| Robin_Watts | http://ghostscript.com/~robin/0001-ForTor.patch was what I came up with. | 11:13.27 |
| | I think I'm of the opinion we should take that patch. | 11:14.21 |
| chrisl | Yeh, that looks like what I was thinking of. | 11:14.39 |
| Robin_Watts | It means that for cidfont fallback, we always fallback to droidsans. | 11:14.50 |
| | It doesn't seem unreasonable (to my ignorant eyes at least). | 11:15.04 |
| | It may not be perfect, but... | 11:15.13 |
| | I have to run helen to the station, back soon. | 11:16.07 |
| chrisl | Robin_Watts: (for when you get back) here's what Acrobat manages when arial.ttf isn't available: http://www.ghostscript.com/~chrisl/2012_03_20_525013_20990-1-uc-edited.png | 11:19.16 |
| | Going to lunch..... | 11:19.44 |
| kens | Ah, the good old bullet font.... | 11:34.34 |
| tor8 | Robin_Watts: bullet font is another option, one that zeniko has asked for in these cases where we know a font is going to fail miserably | 11:50.56 |
| | I think a set of microsoft-font-glyph-index-to-unicode-character tables for handling these cases would be the best solution, short of actually shipping (or digging around the system for) arial.ttf | 11:52.16 |
| | chrisl: mind if I link that screenshot into the bug comments? | 11:53.28 |
| chrisl | tor8: you can link to it, or attach it directly to the bug - it's only ~20k | 11:57.46 |
| | FWIW, I reckon you're going to get asked (well, demanded!) to implement some kind of custom font/CIDfont substitution mechanism in the future, so it might be an idea to add it to the list of future features - then, in cases like these, the solution is simply to map a request for Arial CIDfont to the file arial.ttf (and offload the problem of how to find the TTF to the customer/user). | 11:59.57 |
| tor8 | chrisl: SumatraPDF has custom font loading to find system fonts on windows. non-portable of course. | 12:06.19 |
| | so any customer who wants access to system fonts can do so with only minor modifications to the source. | 12:06.44 |
| chrisl | tor8: yeh, but I think it would better if the "core" source didn't need modified. | 12:07.51 |
| tor8 | our version of the code has calls to pdf_lookup_substitute_font which is a short stub to call pdf_lookup_builtin_font. sumatrapdf has replaced that one function. | 12:09.06 |
| | chrisl: yeah. I think we could add a callback mechanism to the context object actually. | 12:09.54 |
| | or add platform specific code to look for system fonts, and then not be able to reproduce half the bugs that come in :( | 12:10.40 |
| chrisl | tor8: no, my suggestion was meant to *avoid* platform/application specific code in the core, so we leave the problem of finding and enumerating the system fonts to the integrator. | 12:11.49 |
| tor8 | right, so the callback mechanism :) | 12:12.02 |
| chrisl | tor8: is the mupdf core "allowed" to access the filesystem? | 12:12.17 |
| tor8 | chrisl: no. we never touch the file system unless explicitly asked to. | 12:13.04 |
| | no temp files, no looking around for resources, etc | 12:13.22 |
| | that's why we embed the default fonts and cmap data in the binary | 12:13.40 |
| chrisl | tor8: okay, I was just thinking that if you preferred not to use a call back, you could allow the calling app to provide a table of names and font files to substitute - so you could still say only accessing the file system unless told to...... | 12:14.49 |
| tor8 | chrisl: right. table of name->file mapping or callback would both work. a table means we don't have to worry about locking and multithreaded issues, so that may be better. | 12:16.51 |
| | hm, but this is all pdf specific; there's no reason for xps to go looking for system fonts for instance. | 12:17.46 |
| chrisl | tor8: I only mentioned that because I seem to remember you saying you'd prefer to minimize the use of callbacks. | 12:18.04 |
| | Does it matter if it's PDF specific? | 12:18.21 |
| naveen_ | Robin,I'm getting link errors when trying to compile the project...."cmapdump.obj : error LNK2019: unresolved external symbol _aes_crypt_cbc referenced in function _rimage_decrypt_block" | 12:20.28 |
| Robin_Watts | tor8: Not strictly true. | 12:21.59 |
| | The jpeg decoder uses temp files. | 12:22.07 |
| | naveen_: Ah, look for cmapdump.c | 12:22.53 |
| | and add #include "crypt_aes.c" to the top of that ? | 12:24.01 |
| naveen_ | yup..build success | 12:31.45 |
| tor8 | Robin_Watts: it does? (libjpeg) | 12:51.02 |
| naveen_ | Robin,I'm getting this error when i run the cmd: win32\debug\mupdf.exe -o out.png -d encrypted.pdf | 13:02.00 |
| | error: unknown document type: 'C:\WorkSpace\tmp\test.s2g error: cannot open document: C:\WorkSpace\tmp\test.s2g | 13:02.04 |
| | I tried to debug from vs2010 nad it looks like our fz_open_encrypted_file is not getting called | 13:02.46 |
| | I changed pdfapp_open function to call our pdf_open_document...and now it is calling our functions.....got some errors..will debug them..thanks | 13:13.03 |
| Robin_Watts | naveen_: That command should be mudraw.exe, not mupdf.exe | 13:20.03 |
| | tor8: http://bugs.ghostscript.com/show_bug.cgi?id=692985 | 13:20.37 |
| | We use jmemansi.c in the windows and linux builds. | 13:21.22 |
| | That resorts to backing store. | 13:21.28 |
| | If we want it to only use memory we should use jmemnobs.c | 13:21.46 |
| tor8 | Robin_Watts: d'oh! I thought we were using jmemnobs.c | 13:22.42 |
| Robin_Watts | We aren't, and I'd be reluctant to change just before a release. | 13:23.11 |
| tor8 | it's not a big deal anyway | 13:25.21 |
| norbertj | hello chrisl | 13:31.27 |
| | hello henrys | 13:31.55 |
| Robin_Watts | Morning norbertj. | 13:32.15 |
| | chrisl may be at lunch (but is around), and this is a little early for henrys. | 13:32.31 |
| tor8 | Robin_Watts: sanity check on http://git.ghostscript.com/?p=user/tor/mupdf.git;a=commit;h=b9f89048282310db4f54a90a2574b8529dba0bb4 please | 13:32.39 |
| Robin_Watts | Is there something I can help with in their absence ? | 13:32.42 |
| norbertj | I tried to compile pcl on the latest git, I seems to be missing a DNO_UNICODE_WINDOWS in the XCFLAGS in pcl6_msvc.mak | 13:32.52 |
| kens | THat's odd, it works OK for me. | 13:33.14 |
| Robin_Watts | norbertj: Let me check. | 13:33.17 |
| | I can't find NO_UNICODE_WINDOWS anywhere... | 13:34.47 |
| | WINDOWS_NO_UNICODE, it seems :) | 13:35.13 |
| chrisl | norbertj: hello | 13:35.42 |
| Robin_Watts | It is true that I can see language_switch/pspcl6_msvc.mak setting WINDOWS_NO_UNICODE, but not pcl6_msvc.mak | 13:36.09 |
| kens | wonders how my build works in that case.... | 13:36.38 |
| chrisl | I didn't think the PCL code used the the Unicode stuff? | 13:36.47 |
| Robin_Watts | kens: It'll work - it'll just differ in the handling of unicode files passed in. | 13:37.01 |
| | s/files/filenames/ | 13:37.07 |
| kens | Ah.... | 13:37.07 |
| | I believe chrisl is correct, the PCL interpreter doesn't use it | 13:37.45 |
| Robin_Watts | pl/dwmainc.c has reference to it. | 13:37.57 |
| kens | I think that's because I stole it from teh PS interpreter for the display device.... | 13:38.26 |
| norbertj | Robin_Watts: indeed WINDOWS_NO_UNICODE; for me it complained on the conversions for wchar_to_utf8 and viceversa | 13:38.52 |
| Robin_Watts | Well, without windows_no_unicode, pcl stuff gets called through wmain rather than main. | 13:39.05 |
| | It converts the wchars to utf8 and then calls main_utf8 (the function previously known as main) | 13:39.23 |
| kens | I doubt I tested Unicode file names | 13:39.42 |
| | I literally copied the file. | 13:39.53 |
| Robin_Watts | So, unless I'm missing something (which is entirely possible) it looks like it should work. | 13:40.01 |
| kens | SO i probably ended up in there without anyone noticing | 13:40.08 |
| chrisl | OKay, so I should add the definition to the PCL makefile | 13:40.14 |
| Robin_Watts | I thought your pcl display device stuff was done before the unicode stuff ? | 13:40.26 |
| kens | I think that is probably what is missing yes | 13:40.27 |
| | Robin_Watts : I wouldn't swear to that | 13:40.39 |
| Robin_Watts | but I agree with chrisl that we should just add it in any case. | 13:40.42 |
| | norbertj: Thanks for letting us know. | 13:40.58 |
| | tor8: OK. sanity check underway... | 13:41.06 |
| | tor8: Does the impact us being able to open a .rels file ? | 13:42.19 |
| | s/the/this/ ? | 13:42.23 |
| | tor8: I disagree with your comment changes in fitz.h | 13:43.31 |
| tor8 | chartorune and runetochar only convert one character at a time | 13:43.46 |
| Robin_Watts | Yes. | 13:43.58 |
| tor8 | oh. we should add a .rels extension test in fz_document! | 13:44.43 |
| Robin_Watts | On first reading your changes made that less clear to me, but now I've read them again they seem OK. So ignore that objection. | 13:44.51 |
| | Rather than "The path should be utf8 encoded on windows", can we say "The path should be UTF8 encoded on all platforms, even windows where this is not the usual case" | 13:45.56 |
| tor8 | the wording 'string of chars' made me misread your sentence at first, slightly ambiguous at a quick reading | 13:46.01 |
| | well, Linux filenames are encoding agnostic byte strings | 13:46.27 |
| | but on both OSX and Windows they use unicode | 13:46.37 |
| | OSX using decomposed normal form, and windows using precomposed normal form, causing a lot of headaches moving files around | 13:47.20 |
| Robin_Watts | Other than those niggles, it looks good to me. | 13:47.52 |
| tor8 | windows is the only platform I know that uses locales and funky encodings so that plain open() doesn't work | 13:48.16 |
| | I will fix the .rels issue; want to have another go at rewording the rune/char function comments? | 13:48.53 |
| Robin_Watts | tor8: ok... | 13:55.25 |
| | fz_chartorune: UTF8 decode a single rune from a sequence of chars. | 13:58.38 |
| | fz_runetochar: UTF8 encode a rune to a sequence of chars. | 13:58.45 |
| | Trying to avoid using the word 'string' as that has termination implications. | 13:59.10 |
| tor8 | that's better, yes | 13:59.20 |
| chrisl | Huh, no use in pointing norbertj at the commit, then...... | 14:02.10 |
| Robin_Watts | tor8: I'm going to add -ttt into the mudraw usage info. | 14:02.56 |
| tor8 | Robin_Watts: force-updated | 14:02.56 |
| | Robin_Watts: okay. | 14:03.10 |
| Robin_Watts | "The path must be UTF8 encoded on Windows" still bothers me. | 14:04.08 |
| | It makes it sound like windows is the odd one out (i.e. all other platforms will have it encoded some other way). | 14:06.12 |
| | Now, windows may be the odd one out because it NEEDS to be reencoded, but the key thing is that all platforms basically pass in the same thing. | 14:06.59 |
| | In fact, I really don't like the whole of that statement, because the file is NOT how it would be passed to open. | 14:08.47 |
| tor8 | "On windows the filename will be UTF8 decoded and passed to _wopen instead." ? | 14:12.15 |
| Robin_Watts | filename: Path to the file to open. On Windows the filename should be UTF8 encoded so that non-ASCII characters in filenames can be represented safely. Other platforms use their normal encodings to achieve this (for linux and macos this is UTF8 anyway). | 14:13.43 |
| henrys | I skimmed the log is there something I need to do for the Unicode business? | 14:37.55 |
| Robin_Watts | henrys: Nope. | 14:38.16 |
| | chrisl has done it I believe. | 14:38.22 |
| henrys | thanks chrisl | 14:39.01 |
| Robin_Watts | henrys: You have lion on your macbook, right? | 14:39.02 |
| henrys | I do. | 14:39.10 |
| Robin_Watts | ok. USB mobile broadband dongle just arrived, and it needs lion for macs. | 14:39.26 |
| henrys | well that sucks. Lots of folks have resisted lion... | 14:40.26 |
| tor8 | Robin_Watts, henrys: I'm off for a bit, I hope to be back in 1h20m in time for the meeting. | 14:40.37 |
| henrys | okay tor8 | 14:40.50 |
| | Robin_Watts:you included right? | 14:43.22 |
| Robin_Watts | No, I have Lion. | 14:43.34 |
| | I just wish I didn't :) | 14:43.37 |
| chrisl | henrys: np, it was probably me that missed it in the first place (the unicode stuff) | 14:47.35 |
| Robin_Watts | Hullo malc_. | 14:52.27 |
| malc_ | Robin_Watts: heya, 1.0 eh? congrats (and to tor8 too..., well to all of you) | 14:53.00 |
| Robin_Watts | Almost... hopefully the actual release will be today. | 14:53.49 |
| malc_ | Robin_Watts: well, i just noticed the comment mentioning 1 there was no tag... so yeah almost | 14:54.28 |
| Robin_Watts | yeah, that escaped. I wasn't meaning to push that quite yet. Oh well. | 14:54.46 |
| malc_ | Robin_Watts: i just want to sync with 1 and release v12 :) | 14:55.15 |
| | i'm that advanced | 14:55.26 |
| Robin_Watts | Watch for the 1.0 tag going in. | 14:56.10 |
| malc_ | Robin_Watts: i have this third party pdf (hw/sw documentation) with nasty CONFIDENTIAL markers, was wondering if it's easier to remove it via some sort of mupdf device or use camlpdf.. or maybe there are other options? | 14:57.05 |
| Robin_Watts | To remove the 'CONFIDENTIAL' watermarks? | 14:57.33 |
| malc_ | Robin_Watts: aye | 14:57.40 |
| Robin_Watts | Well, that would be a bad thing to do. But hypothetically, I'd use pdfclean -d to decompress the file. | 14:58.16 |
| | Then I'd look in the file to see if I could spot the CONFIDENTIAL marker, and delete it. | 14:58.38 |
| | Then run through pdfclean again to rebuild. | 14:58.45 |
| malc_ | Robin_Watts: i'm not planning of redistributing it, i need to write code based on the data in the doc (which was supplied by manufacturer of th device FWIW) | 14:59.01 |
| chrisl | Possibly emphasis that a bit more just in case big brother is watching: THAT WOULD BE A BAD THING TO DO....... | 14:59.16 |
| malc_ | Robin_Watts: thanks | 14:59.25 |
| | Big brother is in taiwan and judging by the document it's command of the english language is subpar | 15:00.40 |
| Robin_Watts | tor8: For when you return; I've pushed an updated version of your commit onto my repo at casper (just tweaked that comment a bit). | 15:11.49 |
| | Going to do test builds now. | 15:11.54 |
| malc_ | Robin_Watts: i see you are planning to write file(1) replacement | 15:13.22 |
| Robin_Watts | ? | 15:13.37 |
| malc_ | 4b6a1a260468728f545f67771da0d624bf3a8aad | 15:13.46 |
| | speaks of determining file type from contents.. good luck | 15:14.19 |
| Robin_Watts | oh, right. Well, only in so far as we want to be able to recognise between the different filetypes we support. | 15:15.08 |
| | Spotting PDF is easy. | 15:15.17 |
| malc_ | given that cbz and xps are glorified zips | 15:15.24 |
| | that'd be hard | 15:15.29 |
| Robin_Watts | Spotting XPS vs CBZ is trickier as both are zips. But then we just need to open the central directory and look for a .rels file or something. | 15:15.44 |
| tor8 | Robin_Watts, henrys, paulgardiner: back. | 16:02.00 |
| paulgardiner | tor8: hi | 16:02.12 |
| Robin_Watts | hi | 16:02.17 |
| ghostbot | moin moin | 16:02.17 |
| henrys | okay, so let's agree when to meet in the future, tor8 didn't like this time. | 16:02.52 |
| | I'm happy to do earlier if you guys like? | 16:03.07 |
| Robin_Watts | How about tuesdays *before* the other meeting ? | 16:03.09 |
| tor8 | henrys: an hour earlier any day is fine by me. before tuesday meeting would suit me best. | 16:03.26 |
| | 9 PST lands me right when we usually have dinner | 16:03.44 |
| Robin_Watts | so 4pm tuesdays UK time - how would that fit with you paulgardiner ? | 16:03.56 |
| henrys | okay sounds good 8 PST tuesday | 16:04.00 |
| paulgardiner | That's ideal for me. | 16:04.11 |
| henrys | or PDT actually. | 16:04.11 |
| Robin_Watts | I didn't have much to say about paulgardiner's latest report except "Wow" | 16:04.36 |
| | And to suggest that we publish a 'forms' branch on the main repo to which he can push things. | 16:05.08 |
| | And we can periodically pull master into it. | 16:05.14 |
| henrys | it really looks like outstanding progress. | 16:05.36 |
| tor8 | I concur. good work all round. | 16:06.00 |
| | http://git.ghostscript.com/?p=user/paulg/mupdf.git;a=shortlog;h=refs/heads/forms it's already available on casper | 16:06.15 |
| | if paul wants to move the forms branch to the main repo that's good too | 16:06.32 |
| Robin_Watts | oh, well, if it's on casper already then that's fine. | 16:06.49 |
| | It may make sense to keep it in pauls repo, cos we can be free to rebase it then. | 16:07.04 |
| tor8 | yeah, that's one less worry | 16:07.31 |
| henrys | which js engine do you plan to try out paulgardiner? | 16:08.17 |
| paulgardiner | I was wondering whether it was an idea to get some of it on master to avoid repeated rebasing. | 16:08.30 |
| | henrys: That's a good question. I have no idea at the moment. There's a big list on wikipedia | 16:08.59 |
| henrys | are there likely merge conflicts if not rebasing is painless. | 16:09.21 |
| | Robin_Watts:didn't we last look at v8 | 16:09.40 |
| Robin_Watts | When I last looked into this, V8 looked like the smart bet for our purposes (henrys originally pointed me at that). | 16:09.40 |
| henrys | ? | 16:09.41 |
| Robin_Watts | There are lots of engines out there, but most of the capable ones have a license that is no good for us. | 16:10.06 |
| paulgardiner | henrys: a lot of it is in a few new files, but there are changes elsewhere in the code. | 16:10.07 |
| Robin_Watts | If those changes don't radically bloat the code size (and they are extensions to existing interfaces etc) then it may make sense to get them onto master. | 16:10.50 |
| paulgardiner | v8 sounds like a good bet then | 16:10.53 |
| Robin_Watts | The main thing is that we don't want to hurt existing users (with additional code size etc) until we have to. | 16:11.30 |
| henrys | paulgardiner:I do think it important we don't break the regression testing but I doubt you've done that, so I'm all for master but I guess tor8 should have the final say. | 16:11.36 |
| Robin_Watts | v8 only works on x86 and ARM, but what other archs are there really ? | 16:11.56 |
| paulgardiner | Robin_Watts: yeah, I was imagining it would be a decision based on someone having a look over the code, and some would want to go on master. Some not. | 16:12.24 |
| Robin_Watts | I can walk paulgardiner through using the cluster so he can check stuff before pushing. | 16:12.40 |
| paulgardiner | Robin_Watts: Ta. And momento. | 16:12.52 |
| Robin_Watts | paulgardiner: That'd be a code review. We don't do them >8*) | 16:13.09 |
| henrys | do we know what engines are being used on tablets and such typically? I guess apple has something different - does droid have a common js engine? | 16:13.18 |
| paulgardiner | Robin_Watts: :-) | 16:13.19 |
| Robin_Watts | droid uses V8. | 16:13.28 |
| | I believe. | 16:13.34 |
| | (The browser on android is a chrome derivative, I think, and chrome uses V8, so...) | 16:14.00 |
| malc_ | Robin_Watts: there's ppc | 16:14.03 |
| henrys | so we'd just have the v8 in the third party libraries right? That's the only significant bloat. | 16:14.05 |
| paulgardiner | Hopefully the interface between the library and the engine will mean that we wont be stuck with our first choice in any case | 16:14.08 |
| Robin_Watts | henrys: AIUI the core will gain an interface layer to allow things to be plugged into it. | 16:14.50 |
| tor8 | my main worry with v8 (besides it being c++) is the fact it's very tied to specific CPU architectures | 16:14.51 |
| Robin_Watts | We'll then have a small layer of code (a new lib) to match our interface to that of V8. | 16:15.10 |
| paulgardiner | henrys: That's a thought. Yes, it shouldn't be a problem having it in the third party libraries | 16:15.17 |
| Robin_Watts | Plus we'll have V8 itself (in thirdparty) | 16:15.18 |
| tor8 | having a slow as molasses javascript engine that's small and portable would be preferable for our use case, IMO | 16:15.25 |
| malc_ | tor8: spidermonkey | 16:15.48 |
| tor8 | or at least have it as an option, using the same layer/interface as robin just mentioned | 16:15.50 |
| Robin_Watts | So replacing V8 with another lib would mean replacing the small layer of code. | 16:15.57 |
| henrys | tor8:what other alternative meet our licensing needs? | 16:16.02 |
| Robin_Watts | So the only bloat to the core should be in exposing the interface that the small shim library needs. | 16:16.28 |
| tor8 | henrys: that's the big problem... most are gpl. | 16:16.33 |
| | henrys: spidermonkey is MPL ... is that compatible? | 16:17.22 |
| henrys | I haven't carefully parsed MPL but it might be. | 16:18.02 |
| tor8 | I'm okay with shipping "V8 or no javascript, cook your own translation layer if you want to use another engine" | 16:18.08 |
| paulgardiner | Since we hope to support several engines in the long run, might it be ok if some of them were GPL? | 16:18.10 |
| tor8 | paulgardiner: for the gpl release that will be fine. the worry is for paying customers. | 16:18.36 |
| Robin_Watts | paulgardiner: While it's nice to be able to support GPL ones (as a proof that we can support other ones), it doesn't help us from a commercial standpoint. | 16:18.49 |
| | I'd trade supporting a single commercial capable one well for supporting several. | 16:19.16 |
| | http://en.wikipedia.org/wiki/List_of_ECMAScript_engines | 16:19.31 |
| paulgardiner | How much of a complication is C++? Might that rule out some platforms? | 16:22.00 |
| Robin_Watts | paulgardiner: I think gcc is mature enough to work on all platforms we care about. | 16:22.41 |
| paulgardiner | ok good | 16:22.50 |
| Robin_Watts | It's just we'd like to keep mupdf clear of C++. | 16:22.54 |
| henrys | I still like V8 I think we can always depend on google to keep V8 in reasonable condition, not so confident about spidermonkey and mozilla. Of course both should work but at the end of the day I think customers will use what we put in third party so we should try to make a good choice. | 16:23.57 |
| Robin_Watts | MPL is basically "Do what you want, (including mixing it with commercial code) but you must make the source for the MPL stuff available" | 16:24.45 |
| | There is no relinking requirement like there is with the LGPL though, which is the killer. | 16:25.13 |
| malc_ | Robin_Watts: you forgot something | 16:25.14 |
| Robin_Watts | malc_: Go on. | 16:25.22 |
| malc_ | Robin_Watts: IANAL | 16:25.27 |
| Robin_Watts | None of us AL :) | 16:25.37 |
| malc_ | i have one (aunt) sitting in the kitchen right now :) | 16:25.54 |
| | my prior attempts to get her to explain some of the laws to me were fruitless though | 16:26.09 |
| Robin_Watts | so, what did I forget? | 16:26.16 |
| malc_ | IANAL moniker, nothing else.. was just pulling your leg | 16:26.36 |
| Robin_Watts | Ah, right :) | 16:26.42 |
| henrys | great name for a new apple product. | 16:27.04 |
| paulgardiner | :-) :-) | 16:27.31 |
| Robin_Watts | "really great. really simple." | 16:27.32 |
| | http://www.youtube.com/watch?v=Nx7v815bYUw | 16:28.23 |
| malc_ | :) | 16:29.14 |
| henrys | that sums it up. | 16:30.42 |
| Robin_Watts | So, do we have anything left to discuss with paulgardiner? | 16:31.19 |
| | paulgardiner: Any technical sticking points, or are you happy? | 16:31.38 |
| henrys | I don't think so, you've got me reading licenses nows. | 16:31.45 |
| Robin_Watts | Presumably no meeting next week? | 16:31.58 |
| henrys | right I'll be out. | 16:32.23 |
| | paulgardiner:look forward to meeting you in London. | 16:32.51 |
| paulgardiner | Robin_Watts: I don't think so, thanks. Nothing I can't bring up randomly some other time. | 16:33.04 |
| | henrys: Yes likewise. Thanks for the invite. | 16:33.26 |
| henrys | tor8:did you have more. | 16:33.28 |
| | is spidermonkey pure C? | 16:33.39 |
| Robin_Watts | C++ | 16:33.54 |
| | But it has an interpreter, which V8 doesn't have, AIUI. | 16:34.16 |
| tor8 | I don't know of any pure C javascript engines | 16:34.33 |
| malc_ | as tor8 remarked, V8 covers x86[_64] and ARM | 16:34.57 |
| | that's it | 16:35.00 |
| henrys | so I guess paulgardiner will let us know the pitfalls if any exist when he tries to plug in an engine. | 16:35.10 |
| paulgardiner | Does V8 have to interact with an OS's memory management? I'm just thinking there can be comlications in writing out code and then executiing it | 16:35.23 |
| henrys | I can't forsee anything to painful. | 16:35.28 |
| Robin_Watts | paulgardiner: You mean, presumably it must have cache flush stuff for harvard architectures? | 16:35.52 |
| paulgardiner | Robin_Watts: yes that sort of thing. | 16:36.19 |
| Robin_Watts | (If you have separate I and D caches, like on the strongARM, then when you write out your compiled code, it goes into the D cache - and you need to make sure that anything that was in the I cache for that area is flushed) | 16:36.54 |
| | paulgardiner: Presumably it has, but that's all in the engine, I'd hope. | 16:37.09 |
| paulgardiner | Robin_Watts: Yeah. Hopefully not our problem. | 16:37.28 |
| Robin_Watts | Certainly not *my* problem :) | 16:37.42 |
| paulgardiner | I guess as henrys says, we should try it and see. | 16:37.47 |
| | Ok. I think we're sorted. | 16:38.48 |
| Robin_Watts | tor8: I just did builds for the version of mupdf in my repo on casper (i.e. with your latest patch with an updated comment) using VS2005. | 16:39.12 |
| | Each exe is roughly 6.3Meg. Apply upx to them and they go to 2.4Meg. | 16:39.40 |
| henrys | okay thanks for the meeting guys, great work paulgardiner, as Robin_Watts said "wow" | 16:39.49 |
| malc_ | Robin_Watts: real men use kkrunchy not upx. | 16:39.57 |
| Robin_Watts | depacker for kkrunchy is slow. | 16:40.32 |
| malc_ | and kkrunchy is windows exclusive.. but real men care of no such things | 16:40.59 |
| | besides Ryg has released the sources few days ago | 16:41.08 |
| Robin_Watts | Zipped UPX exes are 19.3Meg, zipped normal exes are 23.6Meg | 16:41.56 |
| | tor8: Any thoughts on my changed comment ? | 16:42.22 |
| tor8 | Robin_Watts: I like it. | 16:43.14 |
| Robin_Watts | So, I'll push that to the main repo. | 16:43.27 |
| tor8 | I'll compile and tag the release this weekend or monday. | 16:43.31 |
| Robin_Watts | Fab. | 16:43.49 |
| | Let me know if you want me to do any build testing etc. | 16:44.05 |
| tor8 | I tested that it worked with .rels files too | 16:44.07 |
| Robin_Watts | Ah, fab. | 16:44.15 |
| Robin_Watts | walks dogs. bbiab. | 16:49.05 |
| henrys | marcosw:based on the report I assume we don't need a meeting. | 16:55.16 |
| mvrhel | Robin_Watts | 17:00.20 |
| | when you get back I may want to chat with you about an issue in the sep planar device that I ahve | 17:00.47 |
| | have | 17:00.49 |
| kens | Time to go, night all | 17:03.59 |
| chrisl | mvrhel: has the tiffsep device ever worked reliably for Postscript input? | 17:08.20 |
| mvrhel | chrisl: maybe you will know how best to handle this | 17:08.53 |
| chrisl | uh-oh.... :-( | 17:09.05 |
| mvrhel | so in the case of pdf, I know a head of time, how many spot colors the page includes | 17:09.15 |
| | and as you recall we "reopen" the device if there was a change in the number of spots | 17:09.41 |
| | from the previous page | 17:09.48 |
| | in postscript, this information is not available from the interpreter | 17:10.03 |
| | and so we may start out with cmyk, allocate and do a fill page and some other drawings | 17:10.18 |
| | and then suddenly have a spot color | 17:10.27 |
| | that we need to draw | 17:10.36 |
| | well, unfortunately there is not a planar buffer for this spot color and it is never really properly added with the planar approach | 17:11.01 |
| | in the chunky case, we have 64bits in each pixel so without compressed encoding we can pack in up to 8 colorants | 17:11.43 |
| | with compressed we can add more | 17:11.47 |
| | I was wondering if there is some way or mechanism to add new planes as needed to the memory buffer as least in page mode. in the case of the clist we should be able to work around this issue | 17:12.52 |
| chrisl | I'm a little out of my depth - I thought the color encoding was valid for the entire page? | 17:12.59 |
| mvrhel | so with the planar device there is no compressed encoding | 17:13.28 |
| | every colorant has its own plane | 17:13.34 |
| Robin_Watts | mvrhel: Back. (Though from reading the logs, I kinda wish I wasn't) | 17:14.17 |
| mvrhel | hehe | 17:14.22 |
| chrisl | Yes, but if the compressed encoding is (as i thought) valid for the entire page, then the same problem arises, doesn't it? | 17:14.24 |
| mvrhel | no with compressed encoding we are packing into 64 bit chunky words | 17:14.53 |
| Robin_Watts | but the exact packing scheme depends on the number of components, right ? | 17:15.09 |
| mvrhel | we can readily add new colorants with the existing memory buffer in this case | 17:15.10 |
| | if we did not use compressed color encoding with the non planar case we would be limited to CMYK + 4 spots | 17:15.37 |
| Robin_Watts | So you know the number of colorants before you start rendering anything, but not before we have to allocate the buffer. Is that right? | 17:15.46 |
| mvrhel | Robin_Watts: in the case of PDF, I do know how many colorants will be on the page | 17:16.09 |
| | before allocating | 17:16.13 |
| | in the case of PS I do not know how many colorants there will be until I am already drawing! | 17:16.30 |
| Robin_Watts | OK, that confuses me. | 17:16.40 |
| mvrhel | talk about extreme end points | 17:16.42 |
| | me too | 17:16.47 |
| chrisl | mvrhel: but surely how the values are packed into the 64bit word is dependent on the number of components it has to represent? | 17:17.00 |
| Robin_Watts | Right, what chrisl said. | 17:17.10 |
| mvrhel | so with PDF, the interpreter looks over the data and finds all the unique spot colors on the page | 17:17.15 |
| | and passes that along | 17:17.19 |
| Robin_Watts | suppose you draw some C and M and Y and K. and they get encoded in a particular way. | 17:17.30 |
| mvrhel | this is not an issue with how we encode colors in the non planar case | 17:18.03 |
| Robin_Watts | Then you find a new spot color and you have to draw some Z too. Doesn't the encoding now change? and what has been rendered so far will now change it's meaning ? | 17:18.04 |
| mvrhel | that works just fine | 17:18.06 |
| | ok. lets make an imaginary case | 17:18.28 |
| Robin_Watts | please. | 17:18.33 |
| mvrhel | non-planar | 17:18.41 |
| | I allocate a chunky buffer with 64 bit words | 17:18.54 |
| | I do a fill page, which clears everything | 17:19.06 |
| | I start drawing CMYK stuff | 17:19.14 |
| | lets not worry about the compressed encoding case yet | 17:19.49 |
| Robin_Watts | It's specifically the compressed encoding case that worries me. | 17:20.10 |
| mvrhel | ok, but we are not using that as it is not important to the issue that I have. | 17:20.31 |
| Robin_Watts | I can see how it'll work fine for the non compressed encoding case, as long as the total number of spots doesn't exceed CMYK + 4. | 17:20.34 |
| mvrhel | but I will add it in | 17:20.36 |
| | right. Robin_Watts so with CMYK+1 at 100% there is a special encoding of that value | 17:21.20 |
| | the whole 8 bits of the next byte is not used for the whole spot | 17:21.34 |
| | there is a look up structure that maintains what spots at what levels were added | 17:21.59 |
| Robin_Watts | right. So suppose we encode (0,0,0,0,1) and get value V. | 17:22.00 |
| mvrhel | common cases 100% spot etc are stored | 17:22.15 |
| Robin_Watts | Ok, so (0,0,0,0,0.5) gets V :) | 17:22.30 |
| mvrhel | and this is the issue that has driven this work | 17:22.34 |
| | as we can run out of room | 17:22.39 |
| Robin_Watts | Then later on, we find a NEW spot color. | 17:22.48 |
| | Are we guaranteed that (0, 0, 0, 0, 0.5, 0) would also encode to V ? | 17:23.11 |
| mvrhel | yes. and so we add in a new entry for that pure spot (or what ever color we happen to be drawing with | 17:23.17 |
| | Robin_Watts yes | 17:23.24 |
| | it has the knowledge that all other colorants where 0 | 17:23.48 |
| | it was a pure 100% of the one spot | 17:23.54 |
| | s/where/were/ | 17:24.04 |
| Robin_Watts | Ah, then I need a better example. | 17:24.08 |
| mvrhel | I really dont want to get into describing how compressed color encoding works as it is not the issue here | 17:24.26 |
| chrisl | What happens if we have CMYK + 4 spots already, and then encounter another *new* spot color? | 17:24.59 |
| Robin_Watts | In the general case, if I have encoded a color (c0, c1, c2... ci) and gotten a value V, then am I guaranteed that when we introduce another spot into the equation, that (c0, c1, c2,.... ci, 0) will also encode to V ? | 17:25.11 |
| mvrhel | if we are *not* using compressed color encoding we will have to use the alternate tint transform chrisl | 17:25.24 |
| Robin_Watts | (I don't care about the specific mechanism used. I care about this one property of the mechanism) | 17:25.32 |
| mvrhel | Robin_Watts: yes that is correct | 17:25.55 |
| | to not have it work this way would be very difficult | 17:26.31 |
| Robin_Watts | OK. Then I claim that compressed color encoding doesn't care how many spots are involved. | 17:26.33 |
| mvrhel | yes | 17:26.44 |
| Robin_Watts | (up to its maximum) | 17:26.45 |
| mvrhel | I agree | 17:26.47 |
| Robin_Watts | OK, then I am happy with the chunky ase. | 17:26.58 |
| | case. | 17:26.59 |
| mvrhel | and it really is not valid in the case that I have were we have only ! spot | 17:27.06 |
| | 1 spot | 17:27.15 |
| | in the case with the PDF file, I know that we have 1 spot before I start drawing | 17:27.35 |
| Robin_Watts | So, for the planar case I can see this is a problem. | 17:27.43 |
| mvrhel | so I allocate the proper space as the device is opend | 17:27.52 |
| chrisl | mvrhel: the way it could work in Jaws was that you could setup as many "planes" as you wanted to support, but only allocate, say the first four, the rest were not allocated, and marked as "invalid". When a new spot color was encoutered, you could allocate and "validate" the new raster for that new spot. | 17:28.00 |
| mvrhel | but with PS, we start drawing and *then* we run into the spot | 17:28.13 |
| | chrisl: ah that is clever | 17:28.35 |
| Robin_Watts | mvrhel: Adding new planes to an existing planar device is probably possible. | 17:28.42 |
| | BUT it has some intricacies. | 17:29.08 |
| mvrhel | Robin_Watts: yes this is what I want to do. | 17:29.15 |
| chrisl | mvrhel: it was complicated by the need to handle non-white erasing, but it did work. | 17:29.16 |
| Robin_Watts | Band height calculations for clist will be all thrown out. | 17:29.37 |
| | and by default, I fear all the planes are allocated in one big lump. | 17:30.05 |
| chrisl | With the clist we can accumulate the plate names during interpretation | 17:30.05 |
| Robin_Watts | chrisl: We need to know the bandheight before we start clist interpretation. | 17:30.30 |
| chrisl | Oh, ick :-( | 17:30.41 |
| mvrhel | is it not possible to determine from the PS content how many spots are present on a page like in PDF? | 17:30.44 |
| Robin_Watts | because that sets how many bands, which determines how the band data is chopped up. | 17:30.46 |
| | (It's clist, ick is implied) | 17:30.56 |
| | mvrhel: I am not a PS expert, but I suspect the answer is no. | 17:31.17 |
| chrisl | mvrhel: PS is a stream, you have no advanced notice at all | 17:31.34 |
| mvrhel | ok | 17:31.39 |
| | this issue I should have forseen on this project | 17:32.06 |
| Robin_Watts | So let me look at the code for a mo. | 17:32.10 |
| chrisl | Well formed, DSC compliant PS files should have the colorants required for the page in the DSC header comments - but it's not something we can rely on implicitly. | 17:32.41 |
| | mvrhel: does your current code totally replace the encoded color scheme, or will the two routes be optional? | 17:34.08 |
| mvrhel | chrisl: right now, there is and #ifdef that switches between the two | 17:34.39 |
| | s/and/an/ | 17:35.47 |
| chrisl | mvrhel: I was just wondering if we could just say (at least for the time being) this will only work with fully DSC compliant PS files, and make sure the colorant information is pulled from the comments? | 17:35.50 |
| Robin_Watts | Hmm. gdev_mem_bits_size. We seem to be doing a multiply by using a for loop that adds :) | 17:36.42 |
| chrisl | Robin_Watts: is it intended to cater for planes of different bit depths? | 17:37.16 |
| Robin_Watts | Oh, no. scratch that. It seems that we can (or we were intended to) be able to support different bit depths. | 17:37.23 |
| | chrisl: yeah. | 17:37.26 |
| | So, at the moment, as I feared, we allocate a large lump of memory, and lay the different planes out in it. | 17:37.56 |
| chrisl | :-) Been there, made that mistake (different product, though)! | 17:37.57 |
| | Robin_Watts: but given that we use the line pointers stuff, it probably wouldn't be a huge deal to make each plane a separate allocation, would it? | 17:39.01 |
| Robin_Watts | Either we need to change to a scheme where we have each different plane in a different block of memory (and then have it so we can tack new planes onto the end) or we need to change it to make each plane a separate allocation. | 17:39.16 |
| Robin_Watts | needs to type faster. | 17:39.23 |
| | Whichever scheme we do take we'll need to change the code to allow for us resizing the linepointers array. | 17:39.59 |
| | (more spots, more linepointers). | 17:40.06 |
| | Do we have a maximum number of planes I wonder... | 17:40.26 |
| chrisl | We do have a maximum number of planes, I remember it being discussed...... | 17:40.50 |
| | 32, at moment? | 17:41.05 |
| Robin_Watts | GX_DEVICE_COLOR_MAX_COMPONENTS | 17:41.26 |
| | ARCH_SIZEOF_GX_COLOR_INDEX * 8 | 17:41.42 |
| chrisl | I thought there was a different limit on the allowed planes that mvrhel had stumbled across? | 17:42.34 |
| mvrhel | Robin_Watts: that is not it | 17:43.06 |
| | hold on | 17:43.12 |
| Robin_Watts | Well, that's *a* limit :) | 17:43.18 |
| mvrhel | yes | 17:43.32 |
| Robin_Watts | so that's a limit of 64 anyway, with possibly a lower limit imposed elsewhere. | 17:43.48 |
| mvrhel | yes | 17:43.53 |
| | there is a lower limit hold on | 17:44.01 |
| chrisl | So, would it be a big problem just to allocate enough line pointers for all the possible planes, and just not fill them in until needed? | 17:44.32 |
| mvrhel | that would be nice | 17:44.46 |
| Robin_Watts | That approach is tempting. | 17:45.07 |
| chrisl | I just can't see anyone using something like tiffsep in a limited resource situation. | 17:45.12 |
| Robin_Watts | And we could calculate clist bandheights based on there being the maximum number of planes present. | 17:45.41 |
| mvrhel | right. ray_laptop and I had that discussion a while back | 17:45.49 |
| chrisl | Could be a performance bottleneck with the clist, though..... | 17:46.23 |
| mvrhel | Robin_Watts: we would have two cases | 17:46.25 |
| Robin_Watts | Which is a shame because it means in the no spots case, we'll have 16 times as many bands as before... | 17:46.26 |
| mvrhel | one where it is unknown how many and one where it is known | 17:46.42 |
| Robin_Watts | mvrhel: Have a new PS operator to set the maximum number of spots ? | 17:47.12 |
| | and have the PDF interpreter call that ? | 17:47.23 |
| mvrhel | Robin_Watts: no, right now it is part of the devn structure | 17:47.29 |
| chrisl | Just make it a device parameter. | 17:47.36 |
| Robin_Watts | OK. | 17:47.46 |
| mvrhel | there is a parameter that is -1 if the number of spots is not known | 17:48.00 |
| Robin_Watts | already ? | 17:48.10 |
| mvrhel | and if it has a value, then that *is* the number of spots on the page | 17:48.14 |
| | yes, already | 17:48.17 |
| Robin_Watts | ok, that's spot on (hah!) | 17:48.29 |
| mvrhel | this is known when the call is made to open the device | 17:48.39 |
| chrisl | mvrhel: I think the devn device also has a maximum number of planes, doesn't it? | 17:48.47 |
| mvrhel | yes. that is part of the device color info too | 17:49.04 |
| Robin_Watts | So, I need to make it so that 'base' is an array of 'base' pointers. | 17:49.42 |
| chrisl | So, we'd be able to use the actual number of places, if set, and the maximum number otherwise | 17:49.59 |
| Robin_Watts | and need to add an 'add another spot' call. | 17:50.03 |
| chrisl | s/places/plates | 17:50.20 |
| mvrhel | yes. this all makes sense | 17:50.22 |
| marcosw | henrys: sorry, I was at physical therapy and forgot all about the meeting. But I think you are right, we don't need one. | 17:51.14 |
| Robin_Watts | marcosw: How is the back doing ? | 17:51.26 |
| malc_ | Robin_Watts: confidential gone, thanks | 17:52.18 |
| Robin_Watts | mvrhel: Well, I can start to look into that. | 17:52.23 |
| | malc_: bad man! | 17:52.31 |
| malc_ | Robin_Watts: sue me! :) | 17:52.46 |
| mvrhel | Robin_Watts: is there anything I can do to help with this? | 17:53.15 |
| henrys | marcosw:okay thanks | 17:53.24 |
| chrisl | Robin_Watts: I rather feel that having (or allowing) the plate allocations to be independent is likely to be better for low memory configurations, anyway. | 17:53.27 |
| Robin_Watts | chrisl: Allocating (certainly reallocating) one huge chunk of memory is going to be unfriendly, certainly. | 17:54.03 |
| | I fear this is going to break plib and plan :( | 17:54.46 |
| chrisl | I was thinking of even with a fixed number of plates, it's a large chunk of usable memory, and it's even worse when it must be contiguous..... | 17:55.08 |
| Robin_Watts | Maybe not (plib and plan) | 17:57.54 |
| mvrhel | thats good | 17:57.59 |
| Robin_Watts | yes. | 17:58.01 |
| mvrhel | I don't want to make a bunch of work for you | 17:58.12 |
| Robin_Watts | chrisl: yes. | 17:58.12 |
| mvrhel | Robin_Watts: will any of the low level planar memory procs have to be changed? I am curious since I added a couple | 17:58.55 |
| Robin_Watts | mvrhel: I can work on splitting it into multiple allocations, and leaving room in the lineptrs allocation with what I have. | 17:59.10 |
| | when it comes to adding code to add a new plane, I'll have nothing that can tickle that. | 17:59.31 |
| chrisl | Robin_Watts: I guess it will quickly show up anywhere that *does* make the assumption that the planes are all in one memory allocation..... | 17:59.52 |
| Robin_Watts | mvrhel: I don't know yet. I don't *think* so, but... | 17:59.56 |
| | chrisl: Probably it'll be a bit of code that I added :) | 18:00.18 |
| chrisl | Well, at least you can fix it, and we'll never know! | 18:00.38 |
| mvrhel | Robin_Watts: ok so I should wait until you change to multiple allocations, then I will add in the ability to add a new plane? | 18:01.19 |
| Robin_Watts | mvrhel: I'll do the multiple allocations first. | 18:02.20 |
| | Then either it will be obvious how to add a new one (and I'll write some code and pass it to you untested) or we can discuss it some more. | 18:02.45 |
| mvrhel | ok sounds good | 18:02.54 |
| chrisl | mvrhel: sorry the answer wasn't simpler :-( | 18:02.57 |
| mvrhel | thanks for helping out Robin_Watts | 18:03.05 |
| Robin_Watts | np. | 18:03.13 |
| mvrhel | chrisl: I feared the worst when I stumbled upon this last night | 18:03.16 |
| | many expletives were said | 18:03.44 |
| | since I am so close to having this done | 18:03.59 |
| | this last PS file had me puzzled in its output | 18:04.16 |
| chrisl | mvrhel: well, as I say, depending how much of a nightmare it is, you could have your new code work for when the number of planes is set, and the old code for when it's not - that would take the time pressure off you. | 18:05.05 |
| mvrhel | chrisl: right. | 18:05.56 |
| chrisl | That would get a certain UK based customer off your case, at least ;-) | 18:06.54 |
| Robin_Watts | mvrhel: You could just set the number of planes to max to start with now ? | 18:07.12 |
| mvrhel | Robin_Watts: hmm that might work | 18:07.41 |
| | if it is unknown | 18:07.59 |
| | let me do that once | 18:08.09 |
| | ugly, but I think most of their files are PDF anyway | 18:08.22 |
| | it will probably wreak havoc with the devn dev though | 18:08.55 |
| chrisl | I think they are all PDF - I don't remember ever seeing a PS file from them | 18:09.05 |
| | mvrhel: does -dPageSpotColors get passed to tiffsep, or does it need to go through a setpagedevice, do you know? | 18:12.07 |
| mvrhel | oh gawd. I have not even tested that stuff yet | 18:12.25 |
| | there is also an option for setting the process colors | 18:13.19 |
| chrisl | I only meant, if it does passed from the command line, then setting the default to the maximum number of plates still leaves the option for the user to set their own maximum value. | 18:13.34 |
| mvrhel | oh yes | 18:13.45 |
| | I will check that out chrisl | 18:14.00 |
| | with this ps file | 18:14.05 |
| henrys | Robin_Watts:bmpcmp errors: | 18:15.22 |
| | | 18:15.23 |
| | tests_private__customer_tests__A-109.plt.pdf.ppmraw.600.0 Failed to malloc 1896939792 bytes | 18:15.23 |
| | | 18:15.26 |
| | other than that the bmpcmp seems to look right. | 18:15.34 |
| | odd. | 18:15.39 |
| Robin_Watts | Is that a large page? | 18:17.07 |
| | I bet at 600dpi, it's a huge image, so bmpcmp can't load 2 copies of it into memory. | 18:17.35 |
| | There is a bug in the html output though. | 18:17.50 |
| henrys | yes it is a very large plot. But why would it start doing this now? | 18:18.59 |
| Robin_Watts | Previously you wouldn't have seen the error. | 18:19.14 |
| henrys | ah | 18:19.28 |
| Robin_Watts | OK, that's the html output bug fixed. | 18:19.51 |
| henrys | okay should I regenerate my bmpcmp's? | 18:22.11 |
| Robin_Watts | Well, the html output bug just means that everything gradually moves right on the page. | 18:22.37 |
| | The actual display is correct other than that. | 18:22.52 |
| henrys | okay it doesn't matter I'm probably going to need a few more rounds to fix the current problem anyway. | 18:23.25 |
| | bbiab | 18:23.50 |
| mvrhel | Robin_Watts: so that I can plan what to work on, do you see the update to the planar mem device taking hours/days or weeks? I do realize it is late Friday for you.... | 18:29.06 |
| Robin_Watts | I'm looking now. Give me an hour or so, and I should be able to give you a better guess at a timeframe. | 18:29.47 |
| mvrhel | cool thanks | 18:29.59 |
| chrisl | I'll be off now, 'nite folks...... | 18:36.21 |
| mvrhel | have a good weekend chrisl | 18:36.30 |
| chrisl | You too | 18:36.55 |
| Robin_Watts | mvrhel: We have a problem. | 18:56.59 |
| mvrhel | uhoh | 18:57.06 |
| Robin_Watts | If I allocate the memory buffer in lots of chunks rather than 1 big one, I need to free lots of chunks. | 18:57.56 |
| | but there seems to be some funky stuff going on. | 18:58.09 |
| | and in digging into that, it's lead me to remember something else. | 18:58.26 |
| | If I remember correctly the buffer space is reused in some cunning way by the clist. | 18:59.07 |
| | i.e. during clist writing the space is used by the clist for something, and then it gets used as the render buffer in clist reading. | 19:00.03 |
| | ray may remember more about this. | 19:00.14 |
| | So changing it to be many smaller allocations will break that. | 19:00.35 |
| mvrhel | on phone with ray now | 19:03.14 |
| | oh, ray suggests the initial buffer space could be contingous | 19:05.39 |
| Robin_Watts | and additional allocations should be separate? | 19:06.11 |
| mvrhel | but maybe you should wait until he gets on in a bit... | 19:06.21 |
| | so initially you would allocate a cmyk buffer | 19:07.31 |
| | and that would be used by the writer | 19:07.47 |
| | if additional spot planes are added, those would be used by the reader | 19:08.09 |
| Robin_Watts | Right. That 'just' leaves me the problem of freeing the extras on shutdown. | 19:08.12 |
| mvrhel | well you will need to have some knowledge of a range | 19:08.36 |
| | and a number of chunks | 19:08.44 |
| | that may not be the number of planes | 19:08.49 |
| Robin_Watts | I was planning to have an array of pointers in the device, initially NULL. | 19:09.01 |
| mvrhel | makes things not as nice | 19:09.03 |
| | ah | 19:09.17 |
| Robin_Watts | When I add a plane, I populate a new pointer. At the end I free all the pointers. | 19:09.19 |
| mvrhel | well you still can have an array of pointers | 19:09.24 |
| | the first 4 could just be contiguous | 19:09.39 |
| Robin_Watts | Indeed. pointers 0,1,2,3 would stay NULL. | 19:09.56 |
| | but it looks to me like I never get a call during which time I could free the pointers. | 19:10.20 |
| | The freeing appears to be done by stuff reaching in, plucking the pointer out of the device, and then freeing it outside of the device. | 19:10.59 |
| mvrhel | Robin_Watts: I am not much help in this part | 19:16.39 |
| | I don't understand why pointers 0,1,2,3 are all NULL? | 19:17.15 |
| | oh | 19:17.26 |
| | I see | 19:17.27 |
| | the pointers are just for the new planes | 19:17.32 |
| | not the devices "initial" set | 19:17.48 |
| Robin_Watts | yes. | 19:18.31 |
| mvrhel | where is the pointer for the first 4 planes? | 19:18.38 |
| Robin_Watts | They would be the 'extra' ones I need to free. | 19:18.44 |
| | That would live in 'base' as it currently does. | 19:18.51 |
| mvrhel | ok | 19:18.56 |
| | there must be a way to finalize on the planar device in which case you free up the extras | 19:20.04 |
| Robin_Watts | I'm trying to find it. | 19:20.15 |
| mvrhel | ok | 19:20.19 |
| | brb | 19:20.22 |
| Bo98 | On Android, can MuPDF take PDFs from a web link? | 19:21.17 |
| | Or does it have to be downloaded onto the SD card first? | 19:21.46 |
| Robin_Watts | If you open a PDF file in the browser it should download it, then open it. | 19:21.51 |
| | MuPDF does not support downloading itself, or opening partly downloaded files. | 19:22.24 |
| Bo98 | Okay so I have to download the file onto the SD Card then open it? | 19:23.01 |
| | Right? Or am I getting it wrong? | 19:24.19 |
| | (sort of tired atm) | 19:24.31 |
| Robin_Watts | If you attempt to open a file in the browser (click on the link) then it should set it to downloading in the background. | 19:25.26 |
| | If you then try and open that file, it should launch MuPDF and open that file. | 19:25.49 |
| Bo98 | Ah I get it now. Sorry it's getting sort of late here | 19:26.09 |
| Robin_Watts | Here too. | 19:26.35 |
| henrys | huh I handed off that customer to ray_laptop and he's headed for the hills ;-) | 19:48.37 |
| Robin_Watts | mvrhel: More problems. | 19:51.13 |
| | I was planning to hold the pointers to the added planes in the memory device, but there isn't just one memory device. | 19:52.08 |
| | A memory device gets created then destroyed by the clist renderer on every band rendering. | 19:52.47 |
| | and it just gets passed the memory to use. | 19:53.00 |
| Bo98 | Yes! Yes, yes, yes! | 19:56.48 |
| | Got MuPDF into my existing Eclipse android project. :) | 19:57.21 |
| Robin_Watts | mvrhel: I think this is much too hard to launch into quickly. | 20:05.03 |
| | I'd need to change the setup_buf_device function prototype, and that probably breaks various customer devices. | 20:06.01 |
| | So either I need to get it to realloc the buffer when we add a new spot color, or we need to assume the maximum number of spot colors for postscript. | 20:06.54 |
| | I suspect that just assuming the maximum number for postscript is the best way to go. | 20:07.11 |
| | Going to get food. bbs. | 20:07.22 |
| mvrhel | Robin_Watts: ok | 20:16.43 |
| henrys | sigh that's a lot of hopeful progressions I inspected about 25%. | 20:29.53 |
| | mvrhel:have you heard from ray_laptop today? | 20:31.43 |
| mvrhel | henrys; yes. he was not feeling well today | 20:32.02 |
| henrys | oh okay sorry to hear that. | 20:32.46 |
| | wow he heard us. | 20:33.30 |
| mvrhel | maybe when Robin_Watts comes back they can talk about clist and and planar device and allocating and freeing buffers | 20:34.19 |
| ray_laptop | sorry. As I mentioned to mvrhel, I caught what kept my daughter home sick from Tue until today. I went to bed about 3pm yesterday and just got up around noon. Still rocky, but at least the fever is done (for now) | 20:36.16 |
| henrys | one thing I don't miss since the kids have been out of the house. | 20:37.39 |
| ray_laptop | As I mentioned to mvrhel, there is no problem with re-using the BufferSpace for the known (CMYK) planar buffers initially, then adding some later. | 20:37.44 |
| mvrhel | ray_laptop: Robin_Watts has some issues that came up for him above in the logs | 20:38.15 |
| ray_laptop | as long as the array of 'base' ptrs (that I think Robin_Watts is considering) is used, some planes can be contiguous and others not | 20:38.17 |
| mvrhel | I think he is going to be back from eating soon | 20:38.26 |
| ray_laptop | I'll look at the logs in the meantime. | 20:38.43 |
| | the primary issue is that if we are going to respect the 'BufferSpace/BandBufferSpace' value as the most we will allocate, then the 'automatic' mode has to choose a BandHeight and nbands based on the "worst case" (GS_CLIENT_COLOR_MAX_COMPONENTS) | 20:41.38 |
| mvrhel | ray_laptop: did you see Robin_Watts' comments about the memory device for each band? | 20:43.43 |
| | I don't quite understand that one | 20:43.48 |
| | since you would know the size that you needed during the reading phase | 20:43.58 |
| | and the color info in the clist device would have the information | 20:44.27 |
| | I am missing something | 20:44.48 |
| ray_laptop | mvrhel: I see the comment about the mdev (buffer device) being created for each band. | 20:46.09 |
| mvrhel | also, he says he would need to change the setup_buf_device function prototype | 20:46.52 |
| ray_laptop | mvrhel: I need to look at the planar setup_buf_device to see what it does, but I'm not sure why the prototype would need to change. | 20:48.10 |
| Robin_Watts | back. | 20:49.12 |
| ray_laptop | the multi-threaded rendering doesn't allocate and initialize a buffer device (mdev) on every band it does. I never changed the NumRenderingThreads=0 case to avoid doing that, but maybe I should in case it simplifies some things | 20:50.14 |
| Robin_Watts | My original plan was that I'd keep track of what additional spot colors had been added (and the buffers I'd allocated for them) in the buffer device. | 20:50.41 |
| | but I can't do that, as the device is created/destroyed. | 20:51.00 |
| ray_laptop | as far as when to free 'extra' buffers the mdev may have allocated, that's the same as when we tear down the threads | 20:51.17 |
| Robin_Watts | All I get when it's created is a call to gx_default_setup_buf_device | 20:51.50 |
| | which in turn calls gdev_mem_set_line_ptrs. | 20:51.59 |
| ray_laptop | Robin_Watts: I agree that doing 'on the fly' allocation of extra planes and freeing them on each band would be inefficient | 20:52.09 |
| Robin_Watts | gdev_mem_set_line_ptrs is where we set 'base' to the passed in memory block. | 20:52.20 |
| | So if we are to support extra plane allocations over and above the initial allocation, I need to somehow get that information in gx_default_setupbuf_device (or gdev_mem_set_line_ptrs) | 20:53.15 |
| | ray_laptop: Changing to only creating the buffer device once per page would be a useful step, I think. | 20:54.07 |
| | So, looking at what I have given to me in gdev_mem_set_line_ptrs... | 20:55.03 |
| mvrhel | Robin_Watts: doint you have the device pointer when you do the set up? | 20:55.16 |
| Robin_Watts | I have an mdev pointer to fill in. I have the pointer to the initially allocated block (but no indication of its size). | 20:55.54 |
| ray_laptop | mvrhel: there is a gx_device *bdev | 20:55.54 |
| mvrhel | is that the target device? | 20:56.14 |
| Robin_Watts | I have the raster, and a pointer to where to put the line_ptrs, and the setup height. | 20:56.22 |
| | So in gdev_mem_set_line_ptrs, I do NOT have enough information. | 20:56.37 |
| mvrhel | does mdev already have the color info from the target? | 20:57.21 |
| ray_laptop | Robin_Watts: what is the plane_dev ? | 20:57.31 |
| mvrhel | in gdev_mem_set_line_ptrs | 20:57.34 |
| Robin_Watts | mvrhel: gs/debugbin/gswin32c.exe -sDEVICE=plan -o out.ppm gs/examples/tiger.eps if you want to play along at home :) | 21:00.08 |
| | mdev->color_info looks plausible in gdev_mem_set_line_ptrs | 21:00.55 |
| ray_laptop | Robin_Watts: gdev_mem_set_line_ptrs is NOT a device or buffer proc -- it is a graphics lib utility that is used internally | 21:01.03 |
| Robin_Watts | Indeed, so we could add more info to it. | 21:01.29 |
| mvrhel | ok. well also if you get the profile, there is a boolean that tells you if the device supports devn colors | 21:01.38 |
| | or there will be | 21:01.44 |
| Robin_Watts | the question is, do the places that call it have the extra info we'd need? | 21:01.52 |
| mvrhel | actually there is a special op for it | 21:01.56 |
| | or there will be I mean | 21:02.00 |
| ray_laptop | Robin_Watts: and gx_default_setup_buf_device can do something different for planar devices that have spot colors | 21:02.07 |
| mvrhel | Robin_Watts: if you have a pointer to the device, then you will have the ability to know if you need to support spots | 21:02.48 |
| | is that your question? | 21:03.06 |
| Robin_Watts | Right. And I *don't* have a pointer to the device. | 21:03.12 |
| | Or at least, I don't think I do. | 21:03.18 |
| mvrhel | oh I thought you did | 21:03.20 |
| ray_laptop | BUT (a big but) is that this is primarily for the PS case where we don't know the actual number of spot colors for the page in advance. | 21:03.48 |
| Robin_Watts | In gx_default_setup_buf_device (one of the places that calls gdev_mem_set_line_ptrs), I have a pointer to the buffer device that I am supposed to be setting up. | 21:04.10 |
| | And that's all. | 21:04.15 |
| ray_laptop | I am leaning toward just doing the 'max_color' case (and keeping contiguous planes) | 21:04.37 |
| Robin_Watts | I'm with ray_laptop | 21:04.45 |
| mvrhel | hehe | 21:04.56 |
| | ok so if I have -1, then we do max colors | 21:05.08 |
| Robin_Watts | I think that we should have a device parameter MaxColors (or something) | 21:05.12 |
| ray_laptop | the number of people doing DeviceN with PS is quite rare | 21:05.23 |
| mvrhel | ok. question for you then | 21:05.31 |
| Robin_Watts | The postscript interpreter can set that to the exact number in use. | 21:05.37 |
| ray_laptop | Robin_Watts: I think there is MaxSeparations | 21:05.43 |
| ray_laptop | goes to check | 21:05.46 |
| mvrhel | when we first come in to open the device in there PDF case, we dont have the number of spots on the page | 21:06.01 |
| Robin_Watts | Or people concerned with space can set it to the 'right' value for their job. | 21:06.02 |
| mvrhel | so we open the device as CMYK. | 21:06.10 |
| | later we "reopen" the device with the proper count | 21:06.24 |
| ray_laptop | Adobe claims that MaxSeparations is r/o but I don't mind breaking that | 21:06.31 |
| mvrhel | what is going on with buffer allocations when this occurs? | 21:06.46 |
| | I dont want to allocate the Max the first time through and then allocate something smaller the second time | 21:07.12 |
| Robin_Watts | mvrhel: OK, I maybe about to say something stupid here so... can't we read MaxColors (or MaxSeparations) when we calculate the buffer sizes? | 21:07.19 |
| ray_laptop | mvrhel: in general when 'depth' changes we reallocate (along with width height, etc.0 | 21:07.23 |
| mvrhel | ray_laptop: ok so the first time, we will be doing a large allocation | 21:07.44 |
| Robin_Watts | mvrhel: I think there is a difference between open_device and when we allocate the buffer. | 21:07.45 |
| mvrhel | oh ok | 21:08.02 |
| Robin_Watts | sorry, no. | 21:08.26 |
| ray_laptop | mvrhel: not really -- we will be choosing a smaller BandHeight -- the BufferSpace/BandBufferSpace allocation is capped | 21:08.32 |
| mvrhel | oh ok | 21:08.41 |
| Robin_Watts | It does look to me like the allocation happens in the open call. | 21:08.52 |
| | but I only get one open call to the plan device. | 21:09.00 |
| mvrhel | but we may end up in clist mode the first time with Max colorants where we really did not need to be in clist mode | 21:09.09 |
| | is that true? | 21:09.15 |
| ray_laptop | mvrhel: IFF the user specifies a BandHeight will be open the device with the MaxSeparations number of planes | 21:09.21 |
| Robin_Watts | mvrhel: I would have hoped not, but I've just been confused by what ray said. | 21:09.51 |
| ray_laptop | mvrhel: note that the parameters from the command line get applied BEFORE the device is initially opened. Setting MaxSeparations later (via setpagedevice) will reallocate | 21:10.16 |
| | but if we start in clist mode, then later switch to page mode (not likely) no problem -- happens all the time | 21:11.07 |
| Robin_Watts | I would have expected the device open to happen with max colorants, and we'd calculate that we don't have enough memory, so we'll need a clist mode. So we open in clist mode. But then if we're reopened later with a smaller number of colors, we'll recalculate and may end up not in clist mode. | 21:11.10 |
| mvrhel | fair enough. My plan was to, when the device is opened, if the number of spots on the page is -1 we are going to set the depth of our device according to the max number of seps we can handle | 21:11.29 |
| ray_laptop | mvrhel: that malkes sense | 21:11.51 |
| Robin_Watts | sounds good to me. | 21:11.56 |
| mvrhel | ok. that sounds good | 21:12.01 |
| | I have to go get the kids now | 21:12.24 |
| | thanks for talking this through and thanks for poking at everything Robin_Watts and looking at the planar buff stuff | 21:12.48 |
| ray_laptop | mvrhel: OK. I'll check IRC later | 21:12.51 |
| Robin_Watts | no worries. | 21:12.55 |
| | let me know if there is anything you need me to do. | 21:13.13 |
| ray_laptop | Robin_Watts: I'll look at cleaning up the excessive calls to 'create_buffer_device' that I think can be eliminated (as the threads do) | 21:13.40 |
| | but from testing with NumRenderingThreads=1 vs. =0 it doesn't seem like it helps | 21:14.27 |
| | vs = 0 | 21:14.40 |
| | (chatzilla shows '=' contguous with '0' as a smiley) | 21:15.20 |
| Robin_Watts | I disabled emoticons in chatzilla because it makes pasting code hard :) | 21:15.54 |
| ray_laptop | I think it just looks bad on your view -- when I look at the irclogs I see the emoticons as I typed them not the smiley faces | 21:17.12 |
| Robin_Watts | yes - I'd rather do the ascii -> emoticon translation in my head though. | 21:18.36 |
| ray_laptop | bbiaw -- going to make some tea (ginger and cinammon) for my condition | 21:18.40 |
| henrys | Robin_Watts:for the logs .. confidential files are reason to send the address to scott for a closer look. | 23:38.55 |
| Robin_Watts | ? | 23:39.08 |
| | That was zeniko, the sumatra author. | 23:39.22 |
| henrys | oh I'm sorry I didn't even look at the name, excuse me. | 23:39.37 |
| Robin_Watts | no worries :) | 23:39.44 |
| henrys | I looked at Pedro Rivera - Reported. | 23:40.16 |
| Robin_Watts | Right. Pedro is one of the JMuPDF guys. | 23:40.47 |
| | He's been hammering the multithreading stuff for us. | 23:40.59 |
| henrys | ah okay got it. | 23:41.12 |
| Bo98 | Gonna sleep now. 'night | 23:47.35 |
| Robin_Watts | Bo98: Night | 23:47.59 |
| | Forward 1 day (to 2012/04/21)>>> | |
IRC Logs
