| | <<<Back 1 day (to 2014/07/20) | 2014/07/21 |
| jogux | morning all. new iOS release of mupdf (v1.5) live on the iOS appstore | 08:51.19 |
| | and already our first crashlytics from it in too :) | 08:52.50 |
| kens | chrisl I'm just about ready to throw in the towel on this font stuff. | 08:56.02 |
| chrisl | kens: that bad? | 08:56.24 |
| kens | I cna get *most* of the way thre, but the remaining failure cases are 'complex'. One of them is the Quark Q font using a CID font with type 11 descendants, the output is empty because I get no paths | 08:57.15 |
| | I thought the problem was 'stringwidth' but I no longer think that's it. | 08:57.44 |
| kens | waits for the logs to catch up.... | 08:59.35 |
| chrisl | I haven't typed anything.... | 08:59.46 |
| kens | Well, its still behind what I typed :-) | 08:59.57 |
| | I have about 20 or so files that exhibit problems, and all of them are pretty complex I think (PDF files with text using text rendering modes, weird Quark files etc) | 09:00.40 |
| | I'll see if I can find a simpler case, butif not then I may give up, for now at least | 09:01.12 |
| chrisl | Well, I'll have another quick poke at the solution I looked at, and see if I can get it produce the number of diffs we expect | 09:02.05 |
| kens | Have a try specifically with 067a_stroke-unc.pdf and Bug687845.ps | 09:03.18 |
| chrisl | kens: Bug687845.ps works with my "solution" - need to find 067a_stroke-unc.pdf | 09:11.33 |
| kens | I can mail that one if you need it | 09:11.44 |
| | Its small | 09:11.48 |
| | Oh boy, simplifying a test file causes it ti start working, I hate that :-( | 09:12.46 |
| paulgardiner | kens: almost as bad as "it works in a debug build" :-) | 09:13.46 |
| kens | Yeah, very nearly :-( | 09:13.55 |
| | Great, three blocks of text, remove any of the first 2 and the third appears, leave both, and it doesn't.... | 09:15.04 |
| mattchz | oh, btw, mupdf 1.5 should be out on the app store. | 09:38.29 |
| | (ios) | 09:38.33 |
| | awfully quick review from Apple. | 09:38.46 |
| Robin_Watts | mattchz: Yeah. | 09:38.51 |
| mattchz | itâs normally (or used to be), at least a week. | 09:39.08 |
| chrisl | kens: the rendering devices give the same results for those two files - weird! | 09:40.37 |
| kens | Yeah, I know, so does Acrobat, I'm 'confused'.... | 09:40.52 |
| | Seems to be something to do with the inner loop.... | 09:43.57 |
| | I htink its starting form the same x co-ordinate in each case, and if I shorten the string, it doesn'tr reach teh clip | 09:44.55 |
| | The obvious way to test, is to remove the clip of course | 09:45.16 |
| | And indeed, that is the case | 09:45.43 |
| chrisl | Yep, just got there, too - we skip out of gx_image_cached_char() because we're outside the clip - I still don't see how that has the result it does, though | 09:50.30 |
| kens | Beatsme, but at least I understand what's going on when rednering. Now I need to see why it doesn't work with my hacked pdfwrite | 09:51.12 |
| chrisl | Possibly in the glyph context, pdfwrite is ignoring the clip? | 09:51.55 |
| kens | I htink the clip may be incorrect, but I'm not entirely sure | 09:52.21 |
| | I'm getting incorrect clipping at the moment | 09:52.35 |
| | Which is actually better than completely clipped out | 09:52.46 |
| chrisl | I thought maybe pdfwrite would mess with the clip so it could be sure of getting the entire glyph | 09:53.24 |
| kens | It shouldn't be seeing glyphs at the moment, it should all be paths | 09:53.42 |
| | )and it is, in the output) | 09:53.49 |
| | Hmm, back to completley clipped out :-( | 09:54.13 |
| chrisl | Yes, but your code is still setting up nearly everything to handle the glyph, isn't it? | 09:54.40 |
| kens | Nope, it jumps out pretty quickly now | 09:54.56 |
| | At the top of the text process routine it. It does stil set up an enumerator, but barely more than that | 09:55.27 |
| chrisl | OKay, so "Differences in 11366 of 14344 pdfwrite test(s):" and "Differences in 6256 of 9558 ps2write test(s):" is closer to what I expected! | 09:58.56 |
| kens | Yep, tha'ts more like it | 09:59.07 |
| | did you do a bmpcmp yet ? | 09:59.44 |
| chrisl | No, I was about to when the door bell rang..... | 10:00.11 |
| kens | OK NP | 10:00.16 |
| | I was just going to poke at some of the files I have here as 'interesting' and see what came out for you | 10:00.40 |
| chrisl | I'll throw my patch up on my repo, you can check it out | 10:02.01 |
| kens | OK I'll take a look | 10:02.19 |
| | OK remind me how I do that ? | 10:04.59 |
| chrisl | Hmmm, casper seems slow! :-( | 10:05.10 |
| | kens: you need to stash your changes, then something like: git pull --rebase chrisl master | 10:05.58 |
| kens | already did a stash | 10:06.07 |
| | let me try the git command | 10:06.13 |
| chrisl | Patch is trivial though: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=84bcd913 | 10:06.41 |
| kens | Hmm, well the rebase started :-) | 10:07.01 |
| chrisl | So, for it to head through the stuff I added, run with "-dNOCACHE" | 10:07.33 |
| kens | OK I have that set already | 10:07.41 |
| | I was experimenting with other stuff | 10:07.52 |
| | chrisl first file I tried failed, its the 212-01.ps file | 10:08.53 |
| | Obviously, I went straight to the files causing me a problem.... | 10:09.21 |
| | 067a-stroke_unc.pdf has the same problem as my changes too | 10:09.55 |
| kens | goes off to check his source code, just in case..... | 10:10.14 |
| chrisl | I can't find 067a-stroke_unc.pdf anywhere | 10:10.15 |
| kens | My mistake, try 067a_unc-stroke.pdf | 10:10.38 |
| | Its in the tst suite somewhere | 10:10.52 |
| | Had a quick check and I definitely have your code, not mine | 10:11.36 |
| | and I did a rebuild, so its up to date | 10:11.44 |
| chrisl | kens: what do you mean "failed"? | 10:11.54 |
| kens | THe output of pdfwrite is incorrect | 10:12.02 |
| | Bug687845.ps *does* worj though, which is better than my code | 10:12.44 |
| chrisl | Is that different to files you sent me? | 10:12.48 |
| kens | Might be..... I edited them some more | 10:13.16 |
| | You cna try the original 212-01.ps though | 10:13.25 |
| | Oh, except that I corrutped my copy, oops | 10:14.02 |
| | Bug689290.pdf has hte same problems as my code, 'odd page 1' should be stroked in red, not filled in black | 10:15.05 |
| | bug689006.pdf throws an undefinedrsult error | 10:15.54 |
| chrisl | Well, that's extremely odd, because as far as pdfwrite is concerned, it's just getting "normal" marking ops...... | 10:16.08 |
| kens | Yeah, but that's al;so (more or less) how my change worked, and it has more or less the same set of problems | 10:16.37 |
| chrisl | Well, my skips skips the enumerator, accumulator etc - pdfwrite has *no idea* there's a font involved. | 10:17.30 |
| kens | Bug689692.pdf shows the problems with Tr modes | 10:17.36 |
| chrisl | s/skips/code | 10:17.40 |
| | Tr mode I expect to be a problem | 10:17.58 |
| kens | I had to deal with setcacxhedevice2, as that still calls the pdfwrite set_cache routine, and it gets cross if it doesn't think its dealing with a font | 10:18.35 |
| | Throws an unregistered error. | 10:18.54 |
| | I also did some changes to deal with charpath | 10:19.05 |
| chrisl | isn't the setcachedevice call handled through the enum procs?? | 10:21.53 |
| kens | Ah, yes could be | 10:22.05 |
| | In which case you won't need to handle that | 10:22.11 |
| chrisl | I don't see what would need different handling for charpath, either - it's just a path | 10:22.58 |
| kens | Yes, but you specifically *don't* want to try and handle it as something which isn't a path | 10:23.22 |
| chrisl | Eh? | 10:23.42 |
| kens | However, I notice that pdfwrite inspects the text render mode a lot.... | 10:23.53 |
| chrisl | Yes, with things as they stand, I'd expect tr to work with ps2write, nor pdfwrite | 10:24.24 |
| kens | Hmm, I can try that I guess. | 10:24.38 |
| chrisl | We need to augment the code that tells the pdf interpreter whether the device understands text rendering modes | 10:25.16 |
| kens | Well, we need pdfwrite to say it doesn't if it is not emitting fonts | 10:25.43 |
| chrisl | That's what I mean | 10:25.53 |
| kens | Which means a device parameter, which we need anyway | 10:25.55 |
| chrisl | We already have one for tr | 10:26.09 |
| kens | I mean one to control the font flattening | 10:26.21 |
| | OK looks like I have that fixed now. THere's no obvious way to test the font cache in the device get_params, so I had to add a new devicde parameter | 10:38.23 |
| chrisl | It *must* set the cache size to 0, though | 10:40.47 |
| kens | I've left that as is for now | 10:40.58 |
| | SO you need to set -dNOCACHE as well | 10:41.05 |
| | But I think just setting it to 0 unconditionally, where you currently test it, woudl do | 10:41.26 |
| chrisl | Isn't the fontdirectory in the graphics library context? | 10:41.43 |
| kens | OK I see 212-01.ps is still 'wrong' the third block of text is missing | 10:41.46 |
| | chrisl I don't have anything much in get_params, just the device and a parameter list. I *might* have a saved copy of the graphics state in the device, but get_params is called before the device is set up (if you recall) so I'm not sure I can trust it | 10:42.28 |
| chrisl | Not the graphics state, the gs_lib_ctx, or whatever it's called | 10:43.13 |
| kens | Hmm, is that available ? I'll go check | 10:43.28 |
| | Presuming its the one in the device, and its valid.... | 10:43.45 |
| chrisl | It should be accessible through a memory allocator | 10:43.55 |
| kens | Ah yeah, that shoudl work, the memory pointer must be valid for hte device even if nothign else is | 10:44.21 |
| chrisl | The only hiccup might be that IIRC pcl doesn't (always?) set it | 10:44.45 |
| kens | That would be inconvenient..... | 10:45.05 |
| | chrisl the ccahe.upper isn't 0 when we clal get_params O.O | 10:46.05 |
| | pdev->memory->gs_lib_ctx->font_dir->ccache.upper | 10:47.19 |
| chrisl | kens: the device is probably being initialised before we've all the command line args | 10:47.33 |
| kens | Yes, I wonder if it gets the correct value later..... | 10:47.50 |
| chrisl | Oh, actually, it's probably because -dNOCACHE is handled in gs_init.ps *after* the interpreter is initialised | 10:48.21 |
| kens | I see it go to 0, that will do | 10:48.40 |
| chrisl | kens: did you see my comment about PCL? | 10:49.11 |
| kens | Yeah, I'm not sure what to do about that. | 10:49.44 |
| | THe alternative is to do what I was suggesting, set up a new parameter to pdfwrite, and have it set the cache to 0 when its true. | 10:50.10 |
| | in the text_begin change | 10:50.28 |
| chrisl | I think that would be the safest option, unfortunately :-( | 10:50.35 |
| kens | OK let me set that up now and I@ll run a cluster test | 10:50.49 |
| | WHich will produce many, many diffs to look at...... | 10:50.59 |
| | I'll just do a quck smoke test and make sure I haven't broken something. | 10:51.54 |
| | By the way,I still see 212-01.ps as incorrect | 10:52.20 |
| | The text in the thrid block is completely clipped out, no idea why | 10:52.47 |
| chrisl | It is in rendering devices, too, I think | 10:53.51 |
| kens | But the text render modes worj with pdfwrite now | 10:53.52 |
| | chrisl I see a different result from teh text devices, but it could be something related if you see a problem rendering] | 10:54.14 |
| | I meant rendering devices, not text devices.... | 10:54.32 |
| | OK so cluster push is started | 10:54.58 |
| | I suspect that our changes are in fact equivalent, it was the text rendering modes I was seeing a problem with in my code too. | 10:55.31 |
| | Good grief, where did the morning go ?...... | 10:55.51 |
| chrisl | kens: ah, actually, with x11(alpha) I see the third block clipped out, with ppmraw it's visible..... huh?? | 10:56.52 |
| kens | That's... weird.... | 10:57.03 |
| | FOr me, the display device draws the third block | 10:57.15 |
| | And I was rather assuming it *should* be there from reading the text code | 10:57.35 |
| | Maybe I picked a relly bad test file to focus on :-( | 10:58.05 |
| chrisl | I think it *should* be there, but there does seem to be something odd going on | 10:58.58 |
| | Okay, my car is ready - so I'm going to pick up.... back later | 11:06.28 |
| kens | Good luck :-) | 11:06.38 |
| chrisl_away | Thank! | 11:06.42 |
| | s | 11:06.45 |
| jhabjan | hi, I'm testing Ghostscript and converting simple one page colour pdf to grayscale pdf (pdf contains vector graphics only). The output looks fine (to the eye) and also inkcov device reports all CMY values 0. When converted grayscale pdf is sent to the printer, the printer for some reason counts this page as colour click. Any idea? | 14:05.48 |
| kens | Not really. I'd need to see the PDF file(s) at the very least. I'd have to guess the printer is incorrect htough, if inkcov says the page is k only. | 14:06.51 |
| jhabjan | the other weird thing is that.. on the screen, the pdf looks grayscale, but the printer output is colour. | 14:07.28 |
| kens | It could be something to do with colour conversion of course, if the colours are specified in something other than DeviceGray, the printers colour conversion might map (eg) R=G=B to somethign other than gray# | 14:07.33 |
| | jhabjan : Not much I can say there..... When you say colour do you mean 'a bit coloured' or 'seriously differnt to gray' ? | 14:08.03 |
| | Also, how are you using Ghostscript and what command line etc. | 14:08.21 |
| jhabjan | kens: here is the pdf converted to grayscale: https://www.dropbox.com/s/812dt1ujds2vtfd/test_3.pdf | 14:08.48 |
| | kens: and this is a scan of the printed result: https://www.dropbox.com/s/lvdkgp3fcjt720u/test_3_results.pdf | 14:09.18 |
| kens | Minute, just getting the PDF | 14:09.26 |
| jhabjan | n/p | 14:09.31 |
| kens | Hm, so the logo is in colour. Most likely its a spot colour in the logo, let me see | 14:10.08 |
| jhabjan | this are the options used: -sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray -dCompatibilityLevel=1.4 | 14:10.21 |
| kens | If you are using up to date code you don't need the ProcessColorModel, that gets set fromt eh COlorCOnversionStrategy | 14:11.14 |
| jhabjan | ok, ProcessColorModel was left from when I was testing Mono | 14:12.14 |
| kens | Yep, the PDF file has a colour space with /Separation in it | 14:12.15 |
| | alternate space is DeviceCMYK | 14:12.28 |
| | So the printer is correct | 14:12.52 |
| | Err, this looks like the original PDF file | 14:13.10 |
| jhabjan | ok, any way to make the print result a same as the screen result? | 14:13.33 |
| kens | Producer is Adobe PDF Library | 14:13.34 |
| jhabjan | The producer is Adobe PDF because i had to remove sensitive data out from the pdf | 14:13.53 |
| | the pdf used was the ghostscript result | 14:14.10 |
| kens | OIh dear, I'm afraid I don't trust any file which has been edited | 14:14.14 |
| | And in order to tell you whether there's anything you can do about it, I'd need to see the original PDF file. | 14:14.37 |
| jhabjan | hm.. that will be tricky :) | 14:15.21 |
| kens | Take the original file, ue Acrobat or whatever to remove everything except the logo | 14:15.37 |
| | Run that through pdfwrite and see what happens,if the logo goes grayscale or not | 14:15.53 |
| | If it doesn't then you can send me the file that was edited *before* conversion | 14:16.08 |
| jhabjan | ok | 14:16.11 |
| | secv | 14:16.12 |
| henrys | jhabjan: you can get a support contract with Artifex and weâll agree to an NDA, FWIW | 14:16.31 |
| jhabjan | kens: a same thing, it's converted to grayscale (visible on screen), but printed colour. | 14:22.56 |
| | kens: here is original file: https://www.dropbox.com/s/c2qpgwnojtjspis/test_4.pdf | 14:23.02 |
| kens | OK then I can start with that file | 14:23.04 |
| jhabjan | kens: at this point I'm only testing Ghostscript as possible solution for one print company, so I'm not sure if there is a need for a support contract | 14:24.45 |
| kens | That was henrys, not me ;-) | 14:24.59 |
| | OK *current* code converts the DeviceCMYK alternate space to a DeviceGray alternate space | 14:25.22 |
| jhabjan | kens: yep, sorry, did not notice that | 14:25.29 |
| kens | So the resulting file should print correctly | 14:25.31 |
| | Give me a minute and I'll put the converted file up | 14:25.41 |
| jhabjan | kens: thanks | 14:27.39 |
| kens | is having some trouble with dropbox, will need a couple minutes | 14:27.55 |
| | Still waiting for verification email from dropbox...... | 14:30.27 |
| | jhabjan can I just send this by email to you ? Might be quicker... | 14:31.36 |
| jhabjan | kens: sure, email is fine | 14:35.56 |
| kens | OK what's your address ? :-) | 14:36.11 |
| jhabjan | kens: I just sent you an email to your artifex email.. you can simply reply | 14:37.27 |
| kens | OK will do | 14:37.43 |
| jhabjan | thanks | 14:37.55 |
| kens | OK mail sent | 14:38.14 |
| | Has the converted file as an attachment and teh command line I used | 14:38.31 |
| | I'll be interested ot know what the printer makes of it | 14:38.44 |
| | What *ought* to happen is; for devices that support the spot colour the page will be printed using the spot ink (Pantone Orange somthing or other), for pritners that don't support the spot ink, it shoudl be painted in gray | 14:39.39 |
| jhabjan | kens: got it | 14:40.41 |
| kens | OK let me know how it prints please, I'm interested | 14:40.58 |
| jhabjan | kens: i need to email this file to the print house, will tell them to send me the scan and email you back | 14:41.15 |
| kens | OK that'll be fine | 14:41.28 |
| jhabjan | kens: not sure if they will be able to do it right now, but it should be by the end of the day | 14:41.48 |
| kens | THat's OK I still have many pages of diffs to look at today :-( | 14:42.02 |
| jhabjan | thanks | 14:46.58 |
| | kens: I just got reply back (without the scan), they tested that file on number of printers they have and it prints black/white on all of them except the Xerox one | 15:04.40 |
| kens | Hmm, I guess the Xerox one supports the Pantone colour, it may have its own lookup table and ink substitution | 15:05.22 |
| jhabjan | kens: they raised this issue with Xerox and hopefully the Xerox will resolve this | 15:05.35 |
| kens | Well, explain it at least :-) | 15:05.47 |
| | I'm not really keen on forcing the spot colur back to a Gray equivalent, because it loses important information. It could be done if its essential I guess. | 15:06.30 |
| jhabjan | kens: yep | 15:08.33 |
| kens | jhabjan the Xerox Phaser 840 seems to imply it can do simulation of pantone colours | 15:08.35 |
| | I've no idea if you can disable that | 15:08.50 |
| jhabjan | kens: not sure | 15:09.01 |
| kens | Maybe Xerox can tell the end user..... | 15:09.18 |
| jhabjan | kens: I will check with them | 15:09.54 |
| kens | jhabjan as a test you could edit the PDF file and change all occurences of "/PANTONE#20Orange#20021#20C" to something else, eg "/PANTENE#20Orange#20021#20C" | 15:13.28 |
| | If the Xerox printer is detecting the call for a Pantone spot colour, changing the name of the ink should defeat it | 15:13.52 |
| jhabjan | kens: I will try that, I think I have postscript version of this pdf.. | 15:15.17 |
| kens | You can just change the names in the PDF file | 15:15.32 |
| | THat shoudl work OK | 15:15.43 |
| jhabjan | ok | 15:15.56 |
| kens | As long as you use a binary editor of course :-) | 15:16.05 |
| | Changing one byte doesn't affect the xref table, so it should all be OK | 15:16.26 |
| jhabjan | ultraedit :) | 15:16.33 |
| kens | Well, I use Visual Studio, but anything that doesn't break the file..... | 15:16.50 |
| jhabjan | got it | 15:17.30 |
| | the print house is busy at the moment, they will test the file tomorrow | 15:21.34 |
| kens | NP, just a suggestion to narrow the problem | 15:21.44 |
| jhabjan | will let you know the result with this quick hack | 15:21.55 |
| kens | :-) OK thanks | 15:22.02 |
| jhabjan | n/p, thank you | 15:22.16 |
| Robin_Watts | mattchz: bug 695376 sounds like your area? | 15:39.37 |
| mattchz | Hmm yeah. sounds very much like a bug we put a âhopefulâ fix in for but didnât get feedback from the OP if it helped, so closed it. | 15:41.00 |
| | If it really is v1.3, we should get the to try 1.5 | 15:41.17 |
| | or rather the latest stuff in git. The fix hasnât been released to the playstore yet. | 15:41.40 |
| jhabjan | kens: just got reply back from them, (about Xerox machine) they said that they have changed the Spot Setting and it is now printing fine in mono. // (I didn't get more details) | 15:44.23 |
| kens | I guess htey somehow turned off the pantone substitution, at least its working for them now which is good | 15:44.57 |
| jhabjan | kens: yep | 15:45.15 |
| | kens: anyways... thanks for all help | 15:46.16 |
| kens | NP you;re welcome | 15:46.33 |
| chrisl | kens: the only tests I was really worried about were the ones that threw an unexpected error, and the one that the text came out (was it?) filled back instead of stroked red. | 15:49.26 |
| kens | chrisl those all looked OK | 15:50.02 |
| chrisl | So they may have been tr related? | 15:50.22 |
| kens | One of them defintiely was | 15:50.31 |
| | Probably both | 15:50.42 |
| | Its only the mad QL tests that show any real differences now | 15:50.55 |
| chrisl | Well, the only thing that's disappointing is that it doesn't you get any closer to the type 3 font handling you wanted :-( | 15:51.12 |
| kens | Well it does, kind of, I'm pretty sure that the files with problems in your code are the same as the ones I had (I hadn;'t fixed the Tr either) | 15:51.53 |
| | Which means I should be able to optionally switch the cache on/off and get outlines as required | 15:52.12 |
| chrisl | Ah, true, I guess that makes sense | 15:52.33 |
| kens | Of course, that still doesn't actually work with teh capture, but that's just because pdfwrite is insane | 15:52.33 |
| | I'll need to rework the type 3 font capture, but it should be possible. At least I know that I can do this, and what I need to meddle with to make it work | 15:53.05 |
| henrys | chrisl: I still need the 0 size cache for xpswrite BTW was there a problem setting it at run time? | 15:53.11 |
| kens | I learned quite a bit in the process | 15:53.17 |
| | -dNOCACHE doesn't work for you henrys ? | 15:53.34 |
| henrys | kens: let me check again I thought I looked at that and it did something unexpected. | 15:54.17 |
| chrisl | henrys: it should work as we want, it's just very slightly less efficient with the current FAPI code than it might be - I doubt the difference is significant in this context | 15:54.30 |
| kens | Well it didn't work with pdfwrite, but that's because pdfwrite goes to massive lengths to keep fonts | 15:54.41 |
| chrisl | henrys: there are problems trying to disable the cache dynamically: checking with the device for every glyph would be a performance bottleneck, I feel | 15:55.28 |
| | henrys: we *could* check with the device when we setup the text enumerator - that would probably be less of an issue. But we might run into problems if there's transparency in the mix | 15:57.10 |
| | kens: I'm happy (as much as I can be!) with the set of changes to "flatten" fonts in pdfwrite/ps2write | 15:57.51 |
| henrys | chrisl: what about kens suggestion of NOCACHE | 15:58.09 |
| | ? | 15:58.13 |
| kens | OK wel I'll tidy it up and commit it tomorrow, I'm too tired today I'd mess it up | 15:58.18 |
| chrisl | henrys: I've done all my testing with -dNOCACHE | 15:58.42 |
| henrys | chrisl: okay | 16:01.19 |
| chrisl | henrys: as I said, there's a *slight* inefficiency which I can easily rectify: with the current code we'll try to render the glyph in freetype, realise there is not enough space (because the cache is 0), and retry by creating an outline. It would be preferable to spot the cache size is 0, and go straight to outlines | 16:01.26 |
| henrys | chrisl: I donât think that matters we canât add code to slow things down when using a cache though | 16:02.14 |
| | norbert will spot that ;-) | 16:02.36 |
| chrisl | henrys: we already have a bunch of things to check to decide if we need a outline rather than a bitmap, one extra integer comparison won't hurt! | 16:03.08 |
| henrys | chrisl: didnât they just lay off all the xps people? Canât we just forget about this? :-) | 16:04.44 |
| | chrisl: obviously if you think it a 0 risk change go ahead. | 16:05.29 |
| chrisl | henrys: well, one thing I have concluded is that the cluster performance stats aren't consistent enough, so I will run my own speed tests before committing | 16:06.20 |
| rayjj | henrys: maybe they laid off XPS people because XPS is done. So now they won't be "improving" it and it can finally be made to work ? | 16:06.22 |
| henrys | rayjj: I was joking, I donât know the details of the recent ms lay offs | 16:06.50 |
| chrisl | rayjj: more likely they've decided to develop XPS++ which is a completely new, "improved" PDL, not related to XPS at all...... | 16:07.46 |
| rayjj | henrys: me too. From what I heard is is a lot of Noikia people and "middle managers that impede communication on projects" | 16:07.59 |
| kens | thought that was the purpose of middle managers | 16:08.31 |
| chrisl | Well, the Nokia people is not a surprised - more a surprised it didn't happen sooner | 16:08.34 |
| mlen | rayjj: where can I send the patch? | 16:09.19 |
| rayjj | chrisl: I think it takes a while to make up a list that long :-) Particularly when the managers responsible for the list see their own name on the list -- slows things down a bit | 16:09.26 |
| chrisl | rayjj: :-) | 16:09.55 |
| rayjj | mlen: If you open an enhancement bug -- something like "tiffsep should print out separation equivalent CMYK" then you can attach it there. | 16:10.54 |
| henrys | xbox is doing well at least | 16:11.32 |
| mlen | rayjj: ok, thanks! I'll look into it shortly | 16:11.42 |
| rayjj | Robin_Watts: henrys: where's the agreement that we need on patches ? | 16:12.02 |
| henrys | rayjj: bugzilla where the patch is submitted | 16:13.45 |
| henrys | wonders if michael will have news about the MS move. | 16:14.13 |
| | ? | 16:14.15 |
| Robin_Watts | rayjj: The words "contributor license agreement" link to it on the patch upload page. | 16:14.29 |
| rayjj | henrys: so when mlen (or someone) attaches a patch it notifies the person of the need for the CLA ? | 16:14.44 |
| | Robin_Watts: henrys: thanks | 16:15.08 |
| henrys | chrisl: if this is something you know off the top of your head let me know http://bugs.ghostscript.com/show_bug.cgi?id=695374#c2 | 16:15.26 |
| rayjj | mlen: so as above, when you attach the patch, click on the link to the "contributor license agreement" that we will need in order to include the patch in future releases. | 16:15.59 |
| | mlen: the other nice thing about using the bug tracker is that if I (or anyone) has a suggestion for modifying the patch, we can comment on the bu | 16:16.53 |
| | bug | 16:16.57 |
| | kens: I noticed your reply to Abin confused JBIG2 with JBIG. They want this for fax, which only supports JBIG (not 2) | 16:19.00 |
| kens | rayjj they asked about JPEG | 16:19.14 |
| | "We have requirement of compressing the outgoing fax with JPEG compression for color" | 16:19.38 |
| | The JBIG2 was in a separate bug report | 16:19.53 |
| henrys | kens: and the next feature request is already in... | 16:19.54 |
| kens | Eh ? | 16:20.00 |
| henrys | kens: they have another request on support ... | 16:20.29 |
| kens | Did I miss that one ? | 16:20.38 |
| henrys | like a fire hose | 16:20.38 |
| | just came in | 16:20.46 |
| kens | <sigh> | 16:20.52 |
| rayjj | henrys: that one is from HCL (not cust 130 that Abin is from) | 16:21.45 |
| kens | is tempted to say 'go and do some work yourselves' | 16:21.54 |
| rayjj | henrys: if you are talking about the TRIM box issue | 16:22.18 |
| kens | The customer outsourced to HCL so I feel HCL shoudl do some actual work personally | 16:22.25 |
| henrys | rayjj: right you are | 16:22.49 |
| kens | Tell them they can modify pdf_info.ps to retrieve the information | 16:23.07 |
| rayjj | kens: if the customer were doing the work, we'd probably have an even more difficult time | 16:23.16 |
| | kens: I suspect they want that from mupdf, but it wasn't clear | 16:23.37 |
| kens | The batch file is using pdf_info.ps, that won't work well with MuPDF..... | 16:23.58 |
| rayjj | kens: but if it is pdf_info, then I agree that is trivial (for us) | 16:24.12 |
| kens | leaves it to Marcos | 16:24.39 |
| chrisl | Holy cow, phone call, door bell, phone call....... | 16:28.01 |
| henrys | kens, chrisl : for some reason Iâve seen a few messages using spamcop.net. We want to use the artifex.com address for customers. | 16:28.02 |
| chrisl | henrys: not from me - I don't use spamcop any more | 16:28.23 |
| kens | Hmm, all my my mail *ought* to labelled artifex.com | 16:28.36 |
| chrisl | henrys: I discussed Norbert's report with Ken the other day: it doesn't immediately *look* like a FAPI related issue (based on the comments about copy_portrait), so I was going to leave it to you - but if you want me to take a look | 16:29.27 |
| henrys | chrisl: ah right yours are old, kens used it for Abin today | 16:29.50 |
| kens | Really ? that shouldn't have happened | 16:30.02 |
| chrisl | Having said that, 4% slower: I'm not sure we can measure that accurately...... | 16:30.32 |
| henrys | chrisl: would the extra call be due to cache misses? | 16:31.39 |
| kens | Hmm, looks like its because I'm sending mail via spamcop, though the return address should be artifex | 16:31.52 |
| | Actually no, that's not true either | 16:32.28 |
| kens | is puzzled. | 16:32.34 |
| chrisl | henrys: I don't think FAPI will cause calls to copy_portrait() - I suspect that's happening when imaging cached glyphs. I'll grab the file, and have a look | 16:32.53 |
| kens | None of my mail goes via spamcop any more, so I don't understand that | 16:33.00 |
| chrisl | kens: "reply-to" in Eudora? | 16:33.22 |
| kens | No, that's correct | 16:33.30 |
| | and mail is going via SMTP to relay.plus.net | 16:33.43 |
| chrisl | And I assume you never used a plus.net webmail | 16:34.23 |
| kens | Nope | 16:34.30 |
| | I do sometimes use spamcop webmail, but certainly not today | 16:34.52 |
| | I wonder if its a Eudora personalities hting | 16:36.38 |
| henrys | kens: very strange there seems to be one on july 7 and today and then nothing from spamcop until years back | 16:37.41 |
| kens | Probably since I broke my mail client..... | 16:37.54 |
| | I can't retrieve mail directly from Gmail any more | 16:38.04 |
| | OK it looks like I somehow used the wrong personality, I'm not sure how that happened, its not the default. Probably I clicked the wron gbutton | 16:38.59 |
| chrisl | henrys: these appear to be bitmap fonts, so FAPI cannot be involved....... | 16:39.09 |
| kens | OK time to go, night all | 16:39.21 |
| rayjj | nite, kens | 16:39.57 |
| henrys | chrisl: last I looked we were caching bitmap fonts. | 16:40.00 |
| | bye kens | 16:40.03 |
| chrisl | henrys: and surely the number of calls to copy_portrait() is based on the number of raster lines in each glyph, so I don't see how that would have changed | 16:41.04 |
| | henrys: okay, so we're also calling copy_portrait() from gx_image_cached_char() - again, I'm not really clear why that behaviour might have changed | 16:46.44 |
| henrys | chrisl: the last comment says show_proceed is up 20%. I wonder if we are clipping fewer characters and there is more data, weâve had some changes along those lines, let me check | 16:48.43 |
| | bbiab | 16:49.48 |
| rayjj | kens: (for the logs) I went ahead and answered the question from Sriram (really trivial) | 16:56.21 |
| mvrhel_laptop | the layoffs at MS are mainly in the Nokia group and I think sales is going to be hit | 17:14.54 |
| | the XPS group was long ago disbanded | 17:15.05 |
| | as far as I know | 17:15.17 |
| rayjj | mvrhel_laptop: if you have a chance can you check if App.config was missing from your gsview commit, or if it should be removed from the project. | 17:19.04 |
| | mvrhel_laptop: I (with Robin_Watts' help) have tracked down the other build problems | 17:19.39 |
| mvrhel_laptop | rayjj: I have finished up what I wanted to finish up in the short term in SOT this weekend | 17:31.44 |
| | I will work on gsview now | 17:31.51 |
| | rayjj: I will make sure I can get everything working from a clean checkout and get everything updated. | 17:32.24 |
| | rayjj: what is that you had that needed to be fixed in gsview? | 17:32.36 |
| | I know a couple things that I want to fix | 17:32.51 |
| Robin_Watts | There was a header file in mupdf that didn't like compiling with VS2013 express. | 17:33.14 |
| | so we shuffled some #definery around and it works now. | 17:33.26 |
| rayjj | Robin_Watts: I am getting error: insufficient permission for adding an object to repository database ./objects when I try and push the change to mujs/jsi.h (the compilation fix) | 17:33.28 |
| Robin_Watts | rayjj: Oh, probably only tor8 has pushed to there before. | 17:33.50 |
| | Let me go look. | 17:33.56 |
| rayjj | have to run out for a while. I'll check the logs later... | 17:34.31 |
| mvrhel_laptop | ? | 17:34.37 |
| Robin_Watts | rayjj: Might work now maybe. | 17:36.24 |
| jen_ | Hi, where may I find ready to use libgs.dlylib for Mac? | 17:37.41 |
| mvrhel_laptop | Robin_Watts: are you there? | 17:55.54 |
| | so in the win32 mupdf solution. in the NMake settings for the generated project, the debug has nothing set for its Output but the Release has generated\cmap_cns.h. Is this correct? | 17:57.08 |
| Robin_Watts | I am. | 17:59.05 |
| | The Output field doesn't need to be set. | 17:59.22 |
| mvrhel_laptop | ok | 17:59.26 |
| | for either | 17:59.31 |
| Robin_Watts | yeah, not sure why it's set for one and not the other. | 17:59.45 |
| mvrhel_laptop | ok. np. thanks | 18:00.38 |
| rayjj | Robin_Watts: it didn't work, but I did sudo chmod -R g+w objects branches hooks info logs refs | 19:08.05 |
| | Robin_Watts: now it works | 19:08.09 |
| Robin_Watts | ok. | 19:08.16 |
| mvrhel_laptop | rayjj: are you there? | 19:42.24 |
| | grabbing lunch now... | 19:43.38 |
| | Forward 1 day (to 2014/07/22)>>> | |
IRC Logs