| | <<<Back 1 day (to 2015/01/22) | 20150123 |
| kens | ROFL I see The customer Ray was talking about has gone from 'permanently non supported' to 'full support'. I guess they coughed up some cash :-) | 08:22.20 |
| chrisl | 582? Interesting. I'm pretty sure when I asked last time, Miles reckoned there was no chance of cash appearing from them. I guess things change | 08:28.33 |
| kens | Well, Joann's mail says they are now 'full support'. Maybe one of their bugs turned out to be important to them :-) | 08:29.04 |
| chrisl | The downside is that someone is now going to have to work on the bugs :-( | 08:30.12 |
| kens | Well Ray assigned them both to himself as I recall :-) | 08:30.27 |
| chrisl | Even so, at least one of them sounded like a bit of a horror | 08:30.53 |
| kens | Oh, I don;'t remember what they were, maybe I shold look | 08:31.05 |
| chrisl | The I remember Ray commenting on was multi-Gb clist files - the tiff output takes forever one | 08:31.57 |
| | s/The I/The one I | 08:32.07 |
| kens | Yeah that's a planar device as I remember | 08:32.08 |
| | 695622 | 08:32.34 |
| chrisl | Hmm, yes, I'm not sure why that should make a huge difference to the clist file(s) | 08:32.45 |
| kens | No idea, but its resolution dependent, 720 dpi is slow'ish, 1440 apparently is massive. Maybe patterns or something | 08:33.12 |
| chrisl | At a glance, the PDF doesn't look especially horrific | 08:34.08 |
| kens | No, but I seemto recall its quite astonishingly weird when you decompress it | 08:34.27 |
| | Goes up to 8Mb for starters | 08:34.43 |
| chrisl | Nothing new in that :-( | 08:34.53 |
| kens | Its got 68 sahdings | 08:35.10 |
| | 29 images | 08:35.18 |
| | 26 colour spaces | 08:35.30 |
| | 7 content streams for hte page | 08:35.51 |
| | Lots of filled paths, though I don't see anything too odd about them | 08:36.47 |
| | Almost all the coour spaces are /Indexed /DeviceCMYK, there is one DeviceN space | 08:37.14 |
| | There's overprint but I don't see any transparency immediately | 08:38.55 |
| | Hmm, sometimes it uses 'l' for path construction and sometimes it uses 'L' | 08:40.17 |
| | I'd have to guess its the gradients, presumably using the higher resolution kicks the clist into life and that's what's causing the problem | 08:41.22 |
| chrisl | Are the images rotated to strange angles? | 08:41.50 |
| kens | I didn't look | 08:41.58 |
| chrisl | IIRC, that would drop us out of the high level case in the clist | 08:42.17 |
| kens | and default to billions of rectangles ? | 08:42.33 |
| chrisl | I think so, yes | 08:42.40 |
| kens | I would have thought the cluster woujld show that as a problem if it was one | 08:42.53 |
| | There is some truly weird stuff in this file | 08:43.33 |
| | PDF operators in capitals, and some stuff that I can't see how it ever gets interpreted, its not PDF syntax at all | 08:44.08 |
| chrisl | I'll leave it to Ray for now, I'll pitch in if he needs it.... | 08:44.40 |
| kens | Yeah, back to devices...... | 08:44.49 |
| chrisl | Back to fonts...... | 08:44.59 |
| | Actually, we should probably make sure to point Ray to the new customer list - he might not realise that 582 have been "promoted" | 08:46.08 |
| kens | Ah, all this non-PDF stuff is only referenced from a Provate AI dictionary. SO its not PDF, its the original Illustrator file, stored in the PDF in order to make it nice and big | 08:46.14 |
| | I guess he'll read the logs, even if he misses the email | 08:46.33 |
| chrisl | Argh :-( | 08:46.36 |
| kens | 76 content streams worth of the stuff | 08:47.07 |
| chrisl | I know it's useful in some contexts, but really...... | 08:47.39 |
| kens | I wonder what happens if you run the file through pdfwrite first :-) | 08:47.48 |
| chrisl | It'll probably then go like lightening | 08:48.17 |
| kens | I may give it a try | 08:48.27 |
| | Well, the compressed PDF is 1/4 the size of the original (and converts in seconds) | 08:49.19 |
| | Now to try rendering it | 08:49.26 |
| | Well it certainly doesn't finish quickly, still going | 08:52.40 |
| | And it hasn't started writing an output file, so I guess its making a monster clist | 08:53.01 |
| | Seems to be spending all its time in fill_trapezoid and put_params | 08:53.46 |
| chrisl | So it could be either shadings or images.... | 08:54.48 |
| kens | I have a feeling the put-params is bogus, I seem to recall that 'extended' clist operators all come out as put_params. I did fix that locally while working on the devices, but I never committed it. | 08:54.49 |
| | brb | 08:55.30 |
| | Well its done 8 bands out of 434, obviously going to take a stupendously long time | 09:14.30 |
| chrisl | Can you check the size of the clist file? | 09:15.59 |
| kens | No, I can't find it. | 09:16.06 |
| | It looks like one for Ray though | 09:16.27 |
| | And he had already started looking at it | 09:16.35 |
| chrisl | Oh, well, I guess if it's images or shadings, there's not much pdfwrite can do, whilst preserving the integrity | 09:17.00 |
| kens | No, I think the reason the PDF is smaller is just because it gets rid of all the silly Illustrator gubbins | 09:17.24 |
| chrisl | Yeh, very likely | 09:18.15 |
| kens | Hmm, seems I have to install XMing if I want to debug Linux X applications on Windows using VisualGDB. Oh well, at least it told me..... | 14:01.16 |
| Robin_Watts | kens: Urm... If you want the X apps to display on windows, yes. | 14:07.33 |
| | If you want the X apps to display on the linux box, you don't need to. | 14:07.46 |
| kens | Well I didn't really want it to, I'd have been happy with the X window on my Linux VM< but I guess that would make it hard to debug if it was a remote machine | 14:08.09 |
| Robin_Watts | Xming is pretty innocuous. | 14:08.31 |
| kens | It didn't take long to install | 14:08.41 |
| | Hmm, well I seem to be emitting nothing to the X devices. I wonder why | 14:09.51 |
| chrisl | kens: have you tried just x11 rather than x11alpha? | 14:12.45 |
| kens | I'm using x11 | 14:12.54 |
| chrisl | Specifically on the command line? | 14:13.29 |
| kens | yes -sDEVICE=x11 | 14:13.37 |
| chrisl | OKay, so it's not anti-aliasing getting the way..... | 14:14.03 |
| kens | No, but it seems to be calling the bbox device procs, at least for text_begin | 14:14.25 |
| chrisl | Yes, x11 and co are supersets of a bbox instance - for what reason, I don't know | 14:14.48 |
| kens | Bizarre | 14:14.59 |
| chrisl | I suspect it is probably because you couldn't previously do what you are currently implementing | 14:16.13 |
| kens | So where does it actually copy the bitmap to the X device ? | 14:16.15 |
| chrisl | Well, it has two modes, buffered and unbuffered..... | 14:16.44 |
| kens | O.O | 14:16.50 |
| | OK its not flushing anything to the device, apparently the xdev->update.box is empty | 14:17.27 |
| chrisl | In buffered we render to a mem device, and then blit the results to an X bitmap. In unbuffered we write each object directly to the X bitmap | 14:18.05 |
| kens | I 'think' its buffered, but I'm not sure. | 14:18.23 |
| | In any event, the fact that the update box is incorrect is why its not writing anything | 14:18.43 |
| chrisl | There's a flag in the device "is_buffered" | 14:18.50 |
| kens | is_buffered = 1 | 14:19.10 |
| | The basic problem is that box isn't correct, I need to figure out why that is :-( | 14:19.40 |
| chrisl | You could try forcing to unbuffered with MaxBitmap=0 on the command line | 14:20.31 |
| kens | I'd still need to fix this problem, may as well start where I see the problem, but I should test both modes | 14:20.57 |
| | <sigh> More work...... | 14:21.04 |
| | Well, the fillpage seems to touch the whole page, I guess that's a good place to start | 14:22.35 |
| | OK so it goes to the wrong proc when filling the page, I guess the X device updates the procs after the device gets subclassed. Need to find out where that happens | 14:24.34 |
| chrisl | x_set_buffer | 14:25.12 |
| kens | Ah, thanks, I'll go look at that now. | 14:25.25 |
| chrisl | It changes the procs based on whether it's buffered or unbuffered | 14:25.45 |
| kens | Well that would screw things up..... | 14:26.02 |
| | Hmm well that should not be a problem, because I subclass hte device after that gets done, so the procs shold be OK :-( | 14:27.39 |
| | Must be something else | 14:28.17 |
| Robin_Watts | kens: So VisualGDB is working well for you? | 14:28.44 |
| kens | Oh yes, works very nicely, I;ve used it several times | 14:28.56 |
| | Bought my copy some time back | 14:29.03 |
| Robin_Watts | The only downside to it is that you can't install it on a laptop too :( | 14:29.15 |
| chrisl | kens: I think x_set_buffer() can be called more than once | 14:29.32 |
| kens | Unfortunate, but I don't use it so much that its likely to be a problem | 14:29.45 |
| | chrisl its only getting called once for me (so far) | 14:29.53 |
| | But I'll continue debugging | 14:30.08 |
| chrisl | It may well depend on command line options, or maybe it gets called once per page, or something..... it's a while since ran away screaming from it | 14:30.54 |
| kens | Not to worry, I'm making progress, albeit slowly. | 14:31.08 |
| | Considering it took me nearly 2 days to fix the mswinpr2 device, I'm not unhappy yet | 14:31.29 |
| | Came close to running away screaming form that one too | 14:31.41 |
| | OK so whenI get to the x_bbox_add_rect its pointing at the wrong device. So it updates the rect, but its the one stored in the parent. Just need to find out why now. Coffee first I think | 14:35.30 |
| | OK so the bbox device hides a copy of itself in box_proc_data when its a forwarding device, I hadn't noticed that and need to fix it. | 14:47.06 |
| | Right, that's the basic x11 device working (for some value of working anyway) | 15:08.04 |
| | chrisl can you try the xpswrite device on Linux please ? For me it seg faults trying to run tiger.eps | 15:21.01 |
| chrisl | kens: sure, just building..... any special command line? | 15:22.44 |
| kens | Nothing special I just used -sDEVICE=xpswrite -sOutputFile=/home/ken/out.xps /home/ken/ghostpdl/gs/examples/tiger.eps | 15:23.12 |
| | For me the lj3100sw device seg faults also | 15:23.27 |
| chrisl | xpswrite runs okay for me | 15:24.29 |
| kens | Hmm, odd, I'musing origin/master not my branch | 15:24.45 |
| | Better clean and rebuild | 15:24.51 |
| chrisl | Is it fully up to date? Been a fair amount of activity on xpswrite recently | 15:25.17 |
| kens | I did a pull yes | 15:25.25 |
| | looks like make clean didn't clean the object files out | 15:25.37 |
| | D'oh! make debugclean.... | 15:25.56 |
| chrisl | That would work better..... :-) | 15:26.06 |
| kens | Yes, it sure does | 15:26.19 |
| | Now its building everything | 15:26.26 |
| | well the pcx2up device still seg faults for me | 15:41.50 |
| chrisl | Not for me.... | 15:43.49 |
| kens | Drat | 15:43.56 |
| kens | rebuilds again | 15:44.07 |
| | Nope, still dumps core | 15:44.58 |
| chrisl | You might benefit from rerunning autogen.sh | 15:45.05 |
| kens | OK I'll try that | 15:45.11 |
| | You could be right, I hadn't thought of it, but the makefile may be incorrect | 15:45.32 |
| | Nope, same again | 15:46.20 |
| chrisl | Well, even using -Z@ doesn't cause a problem for me | 15:46.53 |
| henrys | chrisl: urw also provided ttf equivalents for the 3 families only. That also is in my home directory. I think you had this all under rev control somewhere yes? | 15:47.23 |
| kens | Crashes in gdb as well, seems to be executing at adress 0x00 | 15:47.47 |
| henrys | chrisl: I am going to email back and get some clarification on their delivery | 15:47.51 |
| chrisl | henrys: not the TTF ones, only the Type 1 | 15:47.54 |
| henrys | chrisl: I guess we should have something for the TTF's as well. | 15:49.21 |
| kens | OK so I get a seg fault, reliably in pcx2up_print_page | 15:50.44 |
| chrisl | henrys: I'm fine with the TTF equivalents of the Type 1 fonts, but not the TTFs for PCL - I wouldn't want any confusion about the licensing | 15:51.06 |
| | kens: again, any special command line? | 15:51.34 |
| kens | No, nothing special, but I'm baffled by the seg fault, I can't see what would be causing it. The line is: | 15:52.02 |
| | code = (*dev_proc(rdev, open_device)) (rdev); | 15:52.02 |
| | Of course, rdev is a macro..... | 15:52.11 |
| henrys | chrisl: right I guess the 3 new ttf families really have no purpose. | 15:52.32 |
| kens | But the seg fault would suggest its trying to execute 0x00, which would mean that the open_device proc would be 0, and it isn't | 15:52.40 |
| chrisl | henrys: I've no problem putting the TTFs in the repo, "just so they are there"..... | 15:53.10 |
| kens | My command line is : | 15:53.38 |
| | -sDEVICE=pcx2up -sOutputFile=/home/ken/out.bin /home/ken/test.ps | 15:53.41 |
| chrisl | Well, other than the paths and test file (I was using tiger.eps) not a lot of difference | 15:54.33 |
| kens | I think I have a 32-bit build though, any easy way to check ? | 15:54.55 |
| chrisl | Run "file" with the executable as the parameter | 15:55.33 |
| kens | ELF 32-bit LSB executable | 15:55.59 |
| | IIRC VMware doesn't support 64-bit VMs, at least not in the free version | 15:56.21 |
| chrisl | I thought it did now, but you have to have the virtualisation extensions available and switched on in the bios | 15:56.58 |
| kens | I'm pretty sure I do, but there's only one way to find out :-) | 15:57.12 |
| chrisl | Or you could buy VMWare! Or use VirtualBox.... | 15:57.27 |
| kens | VMWare works, I'm loath to change to something else, I had enough trouble getting this working | 15:57.57 |
| | reboot | 15:58.05 |
| Robin_Watts | kens: I run a 64bit VM in VMware player with no problems. | 15:58.15 |
| | admittedly I'm using a 64bit host... | 15:58.23 |
| kens | Well, had to reboot 3 times to read the key I had to press to enter the BIOS, but it says virtualization extensions are enabled. But I've never been able to create a 64-bit VM. | 16:04.01 |
| Robin_Watts | kens: What version of VMWare player? | 16:04.18 |
| kens | Not sure, one moment | 16:04.26 |
| Robin_Watts | 6.0.3 build-1895310 | 16:04.43 |
| kens | 6.0.4 | 16:04.53 |
| | build-2249910 | 16:05.02 |
| Robin_Watts | What 64bit VM do you want? | 16:05.06 |
| kens | Any Linux :-) | 16:05.13 |
| Robin_Watts | http://www.osboxes.org/ubuntu/ | 16:05.34 |
| | I downloaded mine from there. | 16:05.50 |
| kens | Really ? All hte ones I see there are virtualbox, are they compatible ? | 16:06.11 |
| Robin_Watts | It is possible I had to edit a couple of lines to get proper graphical display speed. | 16:06.14 |
| kens | Oh wait, there's a tab | 16:06.19 |
| Robin_Watts | but I can talk you through that editing if required - it's dead simple. | 16:06.45 |
| kens | OK I'll try that tomorrow | 16:06.46 |
| kens | just broke my email so I'd better fix it | 16:07.07 |
| Robin_Watts | If the screen display appears broken when you run it, don't panic. | 16:07.31 |
| kens | OK, I'll bear that in mind | 16:07.45 |
| | Right, mail worknig again | 16:08.01 |
| chrisl | 32 bit build does not crash for me - but then, I've had to leave a load of stuff out..... | 16:08.06 |
| kens | Debugging it under VisualGDB I'm at a loss to see *why* its seg faulting, but it definitely does | 16:08.37 |
| | I may just decide not to care | 16:08.50 |
| Robin_Watts | Aha: Change the .vmx file line virtualHW.version = "7" to "9" | 16:08.57 |
| kens | OK< thanks Robin_Watts I'll try and remember to do that (note to self, remember to read logs!) | 16:09.20 |
| chrisl | All my fedora VMs are 64 bit, so can't check that | 16:10.17 |
| kens | NP I'll try a 64-bit one tomorrow | 16:10.30 |
| | Forward 1 day (to 2015/01/24)>>> | |
IRC Logs