| | <<<Back 1 day (to 2014/05/11) | 2014/05/12 |
| sebras_ | good morning! isn't it a splendid monday monrning? :) | 09:35.07 |
| kens | sebras is obviously on uppers today.... | 09:36.11 |
| chrisl | Good grief, that's too much enthusiasm for a Monday morning!!! | 09:40.15 |
| sebras | just trying to cover up my despair that I again have to survive the entire week to get to the next weekend. | 09:43.52 |
| | this one was fun, but not so... relaxing. ;) | 09:44.09 |
| chrisl | Crikey, now you've gone the other way entirely..... where's that vodka....? :-( | 09:45.31 |
| kens | ah, morning tor8 | 09:54.30 |
| tor8 | sebras: morning? what morning?! did I miss it again? | 09:54.33 |
| kens | tor8 I'm looking at shadings.... | 09:54.49 |
| tor8 | kens: ah, yes. want the 10 mile high overview? | 09:55.22 |
| kens | It looks like there's no way currently for us to recover the function when we get to 'fill_shade', is that correct ? | 09:55.30 |
| | poverview would be good, yes please | 09:55.36 |
| tor8 | kens: no, the fz_function has been sampled into the shade->function array by the time you get it | 09:56.30 |
| kens | Yeah, that's what I feared. | 09:56.39 |
| | For now I can translate that into a Ghostscript smapled function, which is OK for rendering, but not going to be good enough in the long run, for pdfwrite | 09:57.08 |
| tor8 | this was a decision that happened when fz_function still lived in the PDF interpreter (as pdf_function) and shadings in the fitz layer are language neutral | 09:57.19 |
| | we've since made the functions language neutral, so that decision could well be revised | 09:57.44 |
| | and we could stick the fz_function object there instead of having it pre-sampled | 09:57.55 |
| kens | Ah, at some point (not now) that would probably be very helpful | 09:57.59 |
| tor8 | (and then do the sampling in the draw device instead) | 09:58.04 |
| kens | Yeah that will be important for pdfwrite | 09:58.19 |
| tor8 | but for now I'd just make a sampled function from it, and open a bug report to fix what I just said (or I'll forget it) | 09:58.28 |
| kens | Right, I'll carry on with that. | 09:58.41 |
| | It looks like the sample data is an array of floats, 0->1 colorspace+alpha ? | 09:59.02 |
| | I thin with enough head-scrfatching I can wedge that into a GS sampled function and then attach that to the GS shading object. I've picked up most of the data for my fist run at it (a simple linear shading) | 10:00.05 |
| tor8 | yes. 0..1 color in the colorspace + alpha | 10:00.17 |
| | the alpha is used by the XPS interpreter | 10:00.23 |
| kens | Ah, fair enough. | 10:00.30 |
| | I expect I will eventually need to treat the alpha the same as images, but for now I'm going to ignore it :-) | 10:00.56 |
| tor8 | in source/xps/xps-gradient.c:xps_sample_gradient_stops() | 10:01.08 |
| | yeah :) | 10:01.16 |
| | in gxps I had to create a softmask with the alpha as a gray gradient, and mask the color gradient with that | 10:01.36 |
| | we also store 3 types of shadings, if you want to use the data directly you can get at the linear and radial coordinates | 10:01.58 |
| kens | Yes, that's pretty much what I was thinking for both imagews and (now) shadings | 10:02.05 |
| | tor8 yes, I've picked that up formy linear example | 10:02.18 |
| tor8 | or you can use the fz_process_mesh interface to get a callback driven tesselation | 10:02.19 |
| | I suspect you'll want to use the data directly though | 10:02.38 |
| kens | I'd rather pick up the data, as then it works (better) for pdfwrite | 10:02.44 |
| | :-) | 10:02.51 |
| | I'd like to get a simple example working, but as usual the intricacies of Encode/Decode/Range/Domain are confusing me | 10:02.57 |
| tor8 | actually, it looks like 4 types | 10:03.03 |
| kens | Hmm, there's linera/radial pacxked into one | 10:03.20 |
| tor8 | right. so all that Encode/Decode/Range/Domain stuff from the input has been baked into the coords | 10:03.58 |
| kens | 7 types of shading but at least two or 3 of the meshes are handled as one type and linear/radial are packed into one as well | 10:04.00 |
| tor8 | linear and radial are just packed into the same bit of the union | 10:04.16 |
| kens | tor8 Yeah, that's where my headaches start. I suspect as soon as I find a big enough hammer I'll get it sorted :-) | 10:04.22 |
| tor8 | oh wait, the triangular mesh data is stored in the compressed buffer | 10:04.42 |
| | I forgot robin did that :) | 10:04.51 |
| kens | You're way ahead of me there. I'm starting simple :-) | 10:05.03 |
| tor8 | so ... if it's a mesh I'd call the callback interface if I were you | 10:05.03 |
| kens | OK well that's fair enough, I may come back and ask again when I get to complicated shadings.... | 10:05.21 |
| tor8 | and just special case the radial and linear ones | 10:05.23 |
| kens | There seem to be 3 typesin the union, L-or_r (linear or rdaial), m (mesh ?) and 'f' I can't remember whaft that one is. | 10:06.10 |
| tor8 | the mesh processing callback just hands you the data in two passes | 10:06.17 |
| | you can ignore the first pass, which just asks you if you want to preprocess each vertex in the mesh | 10:06.31 |
| kens | OK | 10:06.36 |
| tor8 | and then you get those vertices back in the second step, one triangle at a time | 10:06.39 |
| kens | That seems fair enough | 10:06.50 |
| tor8 | the idea is to do the color conversion into the final colorspace in the first pass | 10:07.04 |
| | and then draw in the second | 10:07.08 |
| | so that the colorspace conversion only happens once per vertex | 10:07.21 |
| kens | Right, well all I really want is the co-ordiunates I guess | 10:07.30 |
| tor8 | but since you want the original vertex data, no need to do the preprocessing pass at all | 10:07.45 |
| kens | RIght. | 10:07.51 |
| | Ah, 'f' must be function based shadings | 10:08.15 |
| tor8 | yeah, I think they're the rectangular function based shading, which we've just taken to sampling into a regular grid | 10:08.42 |
| | you could treat that just like the mesh and use the callback interface | 10:09.08 |
| kens | Hmm, OK well for rendering that's fine, for pdfwrite, might need to thinkabout it (though I suspect these are pretty rare in the real world) | 10:09.16 |
| | Are the COons and Tensor meshes done as triangels too ? (I assume they are, like the Gouraud triangles) | 10:09.44 |
| tor8 | kens: yes. they are subdivided in the callback processor. | 10:10.18 |
| kens | Ah, and the4 shade->type tells me which one we are dealing with | 10:10.21 |
| tor8 | and again, they are very rare in the real world :) | 10:10.48 |
| kens | Oh yeah, I just spotted that there's no 'AntiAlias' in the structure, presumably because MuPDF always applies AA. | 10:11.02 |
| tor8 | actually, for shadings we never apply AA :( | 10:11.14 |
| kens | Oh ! | 10:11.20 |
| tor8 | there are just too many problems with rendering triangle meshes with AA | 10:11.27 |
| | we'd have to keep track of which edges are outer and inner and only AA the outer ones, and then hope that they don't have funky overlapping shapes | 10:11.49 |
| kens | I gues that's true. I've no idea if GS ever applies it (I suspect not)< but again, pdfwrite would need to preserve it | 10:11.53 |
| tor8 | kens: yeah. there's probably quite a number of flags that would need to be preserved that we just drop in the mupdf parser. | 10:12.23 |
| kens | From the spec "This feature | 10:12.23 |
| | may not be implemented on some devices, in which case this flag is ignored" | 10:12.24 |
| tor8 | I think we keep the image->interpolate flag around, but there are likely more | 10:12.47 |
| kens | tor8, Not a problem, just something I need to bear in mind. Getting something rendering is my main goal at the moment | 10:12.54 |
| | Anyway, thanks for the confirmation. I'll go try and work out what magic numbers I need to pass to GS now.... | 10:14.17 |
| | Oh, and I'll open that bug report too. Because otherwise I'll forget also | 10:15.03 |
| tor8 | in source/pdf/pdf-shade.c:pdf_load_radial_shading() it might help to look at the parsing code to understand how the data coming in is processed | 10:16.04 |
| | anyway, the Domain is flattened to 0..1 in the function sampling | 10:16.24 |
| | for radial and linear shadings | 10:16.46 |
| kens | I figured that, since the data is 0->1 in the color space :-) | 10:16.47 |
| | Its more a case of figuring out what I need to cllocate for GS, and getting the numebrs correct. | 10:17.08 |
| tor8 | kens: oh! and if use_function is set, the mesh data is in 0..1 parameter space | 10:17.16 |
| | parameter+alpha | 10:17.28 |
| kens | Ah, I wondered what use_functionwas for | 10:17.31 |
| tor8 | so pure color shadings don't use the function array at all, they have the color data directly in the vertices | 10:17.48 |
| kens | Hmm, OK, I'm sure I'll forget all this by the time I get that far down the list of shading types | 10:18.13 |
| | Hopefully I'll remember we discussed it here :-) | 10:18.26 |
| tor8 | :) | 10:18.29 |
| | Robin_Watts: ping! | 10:20.08 |
| Robin_Watts | pong | 10:43.50 |
| tor8 | Robin_Watts: so I spent the rest of the weekend bashing on the CMaps | 10:44.38 |
| | some commits on tor/master with the results | 10:44.52 |
| andrea__ | someone can use ghostscript with php? | 10:45.36 |
| kens | Many people seem to, yes | 10:46.00 |
| Robin_Watts | tor8: Will look. | 10:46.09 |
| andrea__ | can u help me? | 10:46.21 |
| kens | With what ? | 10:46.35 |
| andrea__ | I want to create a preview for a pdf | 10:47.48 |
| kens | OK | 10:48.07 |
| Robin_Watts | tor8: You said earlier that cmap entries like: | 10:48.15 |
| andrea__ | but i don't know how... | 10:48.21 |
| Robin_Watts | <0123> <0123> 456 | 10:48.25 |
| | were given as <0123> 456 | 10:48.41 |
| kens | andrea__ : Well it depends what you want, PNG, JPEG, TIFF ? resolution ? etc... | 10:48.43 |
| Robin_Watts | in UTF16/UCS2 forms or something... | 10:48.59 |
| andrea__ | i wont png | 10:49.04 |
| | or jpeg | 10:49.09 |
| tor8 | Robin_Watts: they can be given in both forms, depending on whether they're bracketed by begincidchar or begincidrange | 10:49.10 |
| Robin_Watts | Is it worth us pretty printing all the CMAPs into the smallest form? | 10:49.28 |
| | I guess that makes no odds by the time they are compiled though. | 10:49.40 |
| kens | andrea__ OK so use gs -sDEVICE=png16m -sOutputFile=./out%d.png | 10:49.41 |
| tor8 | scripts/cmapcleanx.c will print them in a form with one line per encoding for easier diffing | 10:49.43 |
| | per code point* | 10:49.50 |
| | yeah, it makes no difference there | 10:49.58 |
| | we could ship them in their fully expanded form (all of the <0123>456 form) as well | 10:50.31 |
| andrea__ | What cmap? | 10:52.16 |
| kens | andrea__ : That's a different conversation | 10:52.31 |
| tor8 | Robin_Watts: I'd prefer keeping the original CMaps in their original form since it makes it easier to diff them against upstream | 10:54.07 |
| | but yes, it's certainly possible to print all of them in the most compact form and shave a few megabytes off the source distribution | 10:54.28 |
| Robin_Watts | tor8: If it doesn't make a difference to the compiled size, it's not worth changing. | 10:54.32 |
| tor8 | we might want to ship the processed CMaps in their fully expanded form for easier manipulation | 10:54.53 |
| | but we have both scripts cmapcleanx and cmapcleanz to convert between forms | 10:55.07 |
| | Robin_Watts: right. | 10:55.34 |
| | anyway, the CMap binary size ballooned to 3mb and then with the reuse of common parts came down to 2Mb | 10:55.59 |
| Robin_Watts | which is about the size it was before? | 10:56.21 |
| tor8 | 1Mb :) | 10:56.38 |
| | so we've only doubled it :) | 10:56.46 |
| Robin_Watts | OK. All looks good to me anyway. | 10:56.58 |
| tor8 | but we now do have several CMaps which we didn't use to, and we support all the >16bit code points that we previously skipped | 10:57.13 |
| andrea__ | thanks =) | 10:57.13 |
| kens | No problem | 10:57.20 |
| tor8 | Robin_Watts: I used a couple of hacky diff | sed command line invocations and some manual editing to create these subset CMaps | 10:58.07 |
| | but I expect they'll rarely, if ever, change again so it might not be worth spending time automating the process | 10:58.32 |
| t4nk146 | I was able to cross compile GhostPDL-9.14 to create the pcl6 binary used on an ARM9 RISC. | 11:54.32 |
| kens | Yes, I saw your answer on SO | 11:54.48 |
| t4nk146 | I wanted to thank those that provided the avenues. It was quite the journey. | 11:56.03 |
| Robin_Watts | t4nk146: Glad you got it working. | 11:56.20 |
| kens | Cross-compilation can be awkward. Thanksfor posting your results on SO, that way otehrs can get the benefit also | 11:56.59 |
| t4nk146 | I will be satisfied with the 5 minute print time if that is normal. I assume it is because of the lack processing power. I am used to the Raspberry Pi printing in seconds. | 11:58.38 |
| kens | IIRC you are converting to PDF< so it could be disk access | 11:59.52 |
| | PDF creation involves a lot of access to temporary files, not so much CPU intensive | 12:00.26 |
| | Rendering is more CPU intensive than PDF crfeation. | 12:00.39 |
| | (on average) | 12:00.47 |
| t4nk146 | I am converting text with pcl to pdf from an Allen Bradley controller printout. There is only 32mb of RAM compared to 256 on the RP. The memory usage spikes during the print. | 12:02.17 |
| | As long as it prints, I am happy. We have the time between cycles. | 12:03.35 |
| kens | My knowledge of the PCL interpreter is limited, but its certainly true that the PDF output code uses quite a lot of memory. It has to keep track of all the objects created during conversion, just to start | 12:03.37 |
| | Sticking more memory in might help, if its swapping to disk then it will help a lot. 32Mb seems like a very small amount of memory..... | 12:04.22 |
| | The PDF output code pretty much assumes its running on a workstation rather than an embedded device and doesn't make much attempt to limit its memory usage | 12:05.02 |
| t4nk146 | I have Samba running and that is another bohemoth of memory usage. | 12:07.33 |
| kens | Running both at the same time ? | 12:07.50 |
| t4nk146 | Samba is always running. Even when it is not, the print is still 5 minutes regardless. The "free" command does not provide the cache information in the embedded computer. | 12:10.35 |
| kens | Well, its kind of hard to comment I'm afraid, you could profile the code and see where teh time is used, but it does sound like its simply CPU performance. | 12:11.27 |
| t4nk146 | So far it has not stopped printing and I am running tests continously. Thanks again for all the help. I am out. Cheers! | 12:14.04 |
| henrys | and the snow continues... | 13:50.55 |
| kens | Bright sunshine here | 13:51.08 |
| paulgardiner_lap | Snow?! Really? | 13:51.25 |
| kens | That's what happens when you live in the mountains.... | 13:51.42 |
| henrys | it is late for spring snow | 13:51.42 |
| | we really just started runoff in the mountains | 13:52.23 |
| paulgardiner_lap | I must have a play around with Google street view around where you live sometime. It sounds a beautiful place | 14:04.07 |
| henrys | paulgardiner_lap: it's nice, I'm east of Long's Peak which can be seen everywhere in my town.http://37.media.tumblr.com/3d4883dee9506b3c0f703acafc787541/tumblr_mmcupwz4Hz1qf6462o1_1280.jpg | 14:16.20 |
| kens | That URL seems to giver an access denied error | 14:19.01 |
| tor8 | Robin_Watts: quick review on tor/master when you got a mo | 14:20.17 |
| henrys | kens: it looks like town. is stuck in front of http does this work? http://37.media.tumblr.com/3d4883dee9506b3c0f703acafc787541/tumblr_mmcupwz4Hz1qf6462o1_1280.jpg | 14:20.58 |
| kens | Yes that works. Odd because I stripped off the town. before pastinginto Firfix | 14:21.23 |
| | Nice picture | 14:21.28 |
| tor8 | rain rain rain, I'm sick of all this rain... | 14:21.29 |
| Robin_Watts | tor8: commit looks OK, but commit message looks truncated. | 14:23.34 |
| tor8 | will fix before pushing, thanks. | 14:24.52 |
| | Robin_Watts: kens: do either of you know any PDF test files that have both user and owner passwords, that are both known, non-empty, and different? | 14:55.36 |
| kens | Off hand, no, sorry. | 14:55.49 |
| Robin_Watts | not offhand. | 14:55.53 |
| tor8 | I don't have acrobat on hand to create one either :( | 14:55.58 |
| Robin_Watts | I may be able to make one with acrobat pro | 14:55.59 |
| kens | I made one for testing version 6 security handler | 14:56.03 |
| tor8 | http://bugs.ghostscript.com/show_bug.cgi?id=695101 | 14:56.07 |
| | hard to see what goes wrong when the empty password is accepted | 14:56.21 |
| | if indeed we have a bug in accepting owner passwords | 14:56.33 |
| kens | Could be a problem validating the owner password | 14:56.39 |
| | But I'm fairly certain my revision 6 test with an owner password worked with MuPDF | 14:57.02 |
| tor8 | I could not open that file when I force the password to be 'test' (and skip the test for an empty password) | 14:57.03 |
| kens | Hmmm | 14:57.08 |
| | let me get the fikle | 14:57.13 |
| Robin_Watts | tor8: What version of security handler? | 14:57.23 |
| tor8 | we don't in mupdf make any difference between which password was used to open the file, so it's also hard to see what the bug report is actually about | 14:57.32 |
| kens | Well I can open it OK | 14:57.44 |
| tor8 | Robin_Watts: /V 2 /R 3 | 14:58.00 |
| kens | Acrtobat says its password security acrobat 5 and later | 14:58.01 |
| tor8 | so an old one | 14:58.02 |
| | or not... I keep forgetting which one is which there | 14:58.19 |
| kens | THe password 'test' works to allow me to change the settings | 14:58.26 |
| tor8 | the /Length 128 would imply something newer than rc4 | 14:58.39 |
| | kens: ick. :( | 14:58.55 |
| | maybe we mess something up when we first accept the blank password | 14:59.19 |
| kens | I can't test it with GS, because it will use the user password | 14:59.21 |
| tor8 | that prohibits us from using another password after | 14:59.28 |
| kens | I could add a user password to this file if it helps ? | 14:59.33 |
| tor8 | kens: yeah, that would help | 14:59.40 |
| Robin_Watts | http://ghostscript.com/~robin/tiger_user_owner.pdf | 14:59.41 |
| kens | OK, robin's may be enough but I'll add one here too | 14:59.54 |
| Robin_Watts | That should have user password 'user' and owner password "owner" | 14:59.56 |
| tor8 | Robin_Watts: we can't open that tiger with the 'owner' password :( | 15:00.29 |
| kens | OK I uploaded the file but with a user password added. | 15:02.22 |
| | password is sesame | 15:02.29 |
| mvrhel_laptop | good morning | 15:03.19 |
| tor8 | kens: thanks. | 15:03.24 |
| kens | NP | 15:03.28 |
| | Hi Michael | 15:03.33 |
| tor8 | kens: can't open with 'test' but can open with 'sesame' :( rats! | 15:03.51 |
| kens | I did try that installer on my Windows (.0 VM and had the exact same problem | 15:03.54 |
| tor8 | mvrhel_laptop: I tried the installer on my win7 machine and couldn't open either. got an error message about not being able to find the mupdf dll | 15:04.23 |
| kens | ah same as me | 15:04.39 |
| tor8 | Robin_Watts: spring insomnia sale on gog.com | 15:07.35 |
| henrys | Robin_Watts, paulgardiner_lap : do you guys want video conferencing units for debugging? The folks that managed picsel's liquidation would like to send them somewhere. I can't imagine them being useful but I was asked. | 15:21.12 |
| Robin_Watts | henrys: Presumably that's glorified skype, right? | 15:22.03 |
| | i.e. this is just office kit, rather than stuff we're supposed to interwork with ? | 15:22.23 |
| henrys | they are "UC360 Video conferencing units" | 15:23.13 |
| paulgardiner_lap | How much do they go for on ebay? :-) | 15:23.43 |
| henrys | I say we get them only if miles will use them for quarterly meetings ;-) | 15:24.28 |
| Robin_Watts | henrys: They want to give them away? Or they want us to pay for them? | 15:24.45 |
| henrys | free | 15:24.56 |
| paulgardiner_lap | Oh. Could be interesting because of who makes them. Am I right in recognising that name? | 15:25.36 |
| Robin_Watts | If they are giving 'em away, I say get 'em. Can't hurt. | 15:27.13 |
| henrys | we'll just send them to miles office... | 15:27.19 |
| paulgardiner_lap | I'd agree | 15:27.33 |
| pedro__ | aren't they the Polycom units? | 15:28.18 |
| | if so they were pretty decent | 15:28.42 |
| mvrhel_laptop | tor8: yes. I need to look into that today. I have a win 7 machine here | 15:32.36 |
| henrys | mvrhel_laptop: I didn't have problems with NET 4 is there some feature that requires 4.5 which I'm not using in a smoke test? | 15:33.31 |
| mvrhel_laptop | henrys: I am surprised it works with Net 4. Some of the async calls that I am using are only available in Net 4.5 | 15:34.22 |
| | henrys: you are running windows 8 thoug? | 15:34.44 |
| | that will have net 4.5 | 15:34.57 |
| henrys | mvrhel_laptop: I've checked it with the command line tool and installed program gui - and it only says 4 | 15:36.43 |
| | mvrhel_laptop: oh nvm you are right | 15:38.18 |
| mvrhel_laptop | henrys: ok | 15:39.30 |
| | my plan is to replace these calls and get this down to net 4. | 15:40.16 |
| | below net 4 would be possible, but I will show you in the meeting what the downside of this is | 15:40.50 |
| | need to grab some breakfast | 15:41.34 |
| | brb | 15:41.36 |
| Robin_Watts | net 4 runs on XP SP3 and above. | 15:41.52 |
| | so that sounds fair enough. | 15:42.03 |
| mvrhel_laptop | ok. well that will be my goal | 15:42.06 |
| | it should not be too hard. just need to replace some of the async continue calls with more traditional thread calling set ups | 15:42.51 |
| Robin_Watts | 4.5 is vista and above. | 15:43.02 |
| mvrhel_laptop | oh intereseting | 15:43.13 |
| henrys | mvrhel_laptop: let's not worry about that unless we get requests, we have to get you onto the next torture rack ;-) | 16:05.36 |
| mvrhel_laptop | henrys: ok that probably makes sense | 16:06.39 |
| kens | OK time to go eat, goodnight all | 16:23.37 |
| mvrhel_laptop | ok. I now see the issue with the installer. | 16:28.26 |
| zeniko | Robin_Watts: tor8: there are three small changes on zeniko/mupdf for review when you get some time to spare | 16:39.36 |
| | tor8: is there any reason cmap.h uses unsigned ints instead of plain ints? | 16:48.16 |
| Robin_Watts | code point entries can never be negative, right? | 16:48.47 |
| zeniko | currently, pdf_add_codespace converts from int to unsigned int and pdf_decode_cmap back to int (and MSVC complains about signedness mismatched comparisons) | 16:49.06 |
| Robin_Watts | probably it all ought to be unsigned int now. | 16:49.31 |
| | but I don't know if we use -1 to mean "not found" or anything. | 16:49.41 |
| | tor8 updated the cmap stuff to cope with > 16 bit codepoints at the weekend. | 16:50.02 |
| zeniko | (pdf_lookup_cmap does return -1) | 16:50.10 |
| Robin_Watts | possibly we need to rethink that then. | 16:50.35 |
| zeniko | yeah, I've just been merging these changes and got compilation breakage | 16:50.40 |
| | because MSVC warns about the signedness differences and we don't tolerate warnings | 16:50.56 |
| mvrhel_laptop | ok. Ms really screwed up partnering with installshield for a lite version of their installer, which has problems. and of course the non-lite version cost is crazy. apparently enough people have complained that the just last month provided a VS extensions for 2013/2012 that brings back the old installer from VS2010 | 17:16.35 |
| | moving to that installer... | 17:16.51 |
| | breaking for lunch | 18:11.50 |
| tor8 | Robin_Watts: zeniko (for the logs): the input code points to a cmap need to be unsigned int because the CMaps decode UTF-8 as 4-byte ints where the highest bit can be set | 20:29.49 |
| | I'll take a look at fixing the signedness one way or another | 20:31.38 |
| zeniko | tor8: thanks for looking into the signed/unsigned warnings | 20:54.23 |
| | tor8: my tests show a single behavior change from the cmap changes: | 20:54.48 |
| Robin_Watts | tor8: Are we safe to assume that FFFFFFFF is never valid? | 20:54.51 |
| zeniko | <00a0> maps to U+0020 instead of U+00A0 for Identity-H | 20:55.32 |
| | is that change intentional, an omission from the new cmaps or a bug in your compacting tool? | 20:57.20 |
| tor5 | zeniko: that's unintentional and unexpected ... Identity-H is special cased to never actually load a CMap. | 21:10.09 |
| | Robin_Watts: yes, -1 can be safely assumed invalid | 21:11.17 |
| zeniko | tor5 (for the logs): it's not Identity-H after all but an embedded cmap which apparently maps one cid to both U+0020 and U+00A0 and due to some pdf_lookup_cmap_full now returns the first instead of the second mapping | 22:27.00 |
| | Forward 1 day (to 2014/05/13)>>> | |
IRC Logs
