| | <<<Back 1 day (to 2014/04/28) | 2014/04/29 |
| Ziai | hi all :) | 07:06.10 |
| | perhaps someone could help with this? http://pastebin.com/dZBLdbbX | 07:06.53 |
| kens | chrisl when generating temporary files, on Linux, do we use tmpfs ? | 07:06.54 |
| | Ziai : what help did you expect / THe message seems clear to me | 07:07.19 |
| chrisl | kens: we don't really control what filesystem we use | 07:07.45 |
| kens | chrisl oh, on Windows we use CreateTemporaryFile() (or whatever its called), I was hoping we did something similar on Linux | 07:08.15 |
| chrisl | That gives you a path, not the filesystem | 07:08.32 |
| kens | Yes, but if the Windows temporary path is set up to be on a ram disk, then you get a ram file system. | 07:08.59 |
| chrisl | Yes, but we don't control that | 07:09.10 |
| kens | THis is an SO question: | 07:09.16 |
| | http://stackoverflow.com/questions/23257633/ghostscript-convert-pdfs-to-other-filetypes-without-using-the-filesystem/23262617?noredirect=1#comment35761573_23262617 | 07:09.16 |
| | THe last comment there is beyond my Linux expertise... | 07:09.47 |
| | I have no idea what he means by 'server mde' for instance | 07:10.12 |
| chrisl | Using the server loop? It's not a Linux thing, AFAIK | 07:10.30 |
| kens | But he mixes it with tmpfs, which is an OS thing..... | 07:11.00 |
| | I gues I'll have to ask him | 07:11.11 |
| chrisl | tmpfs is effectively a ramdisk for temp files, but there's nothing to tell us that that a given directory is is tmpfs or some other file system | 07:11.58 |
| kens | Yes, I understand that, but. But when we create a temporary file, what path do we use (on Linux) ? | 07:12.58 |
| | On WIndows I know we use the system temporary path. | 07:13.40 |
| chrisl | So, we'll generally use the value of the TMPDIR or TEMP environment variable - and probably default to /tmp otherwise | 07:14.10 |
| kens | OK so I guess I can tell him to set TMPDIR and TEMP and he'll be ok | 07:14.31 |
| chrisl | He could setup a tmpfs mount, and point TMPDIR to it, and gs should use it | 07:14.55 |
| kens | My memory was faulty, its the GetTempFileName() call we use on Windows | 07:14.56 |
| chrisl | Does that get the path, too? | 07:15.08 |
| kens | THat's probably good enough for an answer | 07:15.11 |
| | chrisl I htink so yes | 07:15.17 |
| | Oh there's a GetTempPath too | 07:15.37 |
| chrisl | On Linux we'll use the environment variable(s) to get the path, and then we use mkstmp64 (IIRC) to get the file name | 07:16.00 |
| kens | Good enough I don't believe he cares about the name. | 07:16.20 |
| chrisl | Oh, actually, it's mkstemp64() | 07:16.39 |
| | If it's available.... | 07:16.46 |
| | Hmm, seems to me that five minutes of reading could have solved his "problem" without bothering people on SO. | 07:18.03 |
| kens | People on SO aren't good at doing their own research.... | 07:18.28 |
| | Hmm chrisl is a t530, is that an early version Terminator ? | 08:48.44 |
| chrisl_t530 | It's a Lenovo laptop model...... and I think it *is* taking over | 08:49.24 |
| pedro__ | hi folks | 09:04.02 |
| kens | Morning | 09:04.07 |
| norbertj | kens: good morning | 09:04.47 |
| | chrisl: I added some questions on 695190, (pclperf problems), could you have a quick look? | 09:05.45 |
| chrisl_t530 | norbertj: UFST is slower - for a number of reasons | 09:06.30 |
| | norbertj: and the extra memory is because we have to buffer more data for the individual TTF files than for the MT fonts | 09:07.31 |
| norbertj | chrisl_t530: that I understand, but for cmp_02_08 I see a lot of downloaded bitmap characters, that (I think) are not rasterized by ufst. | 09:08.07 |
| chrisl_t530 | norbertj: they are not touched by Freetype either | 09:08.42 |
| norbertj | chrisl_t530: ufst gsromfs1_.c 4.6 MB, freetype 15.8 MB | 09:09.14 |
| chrisl_t530 | norbertj: yes? | 09:09.30 |
| norbertj | chrisl_t530, is there a per character extra overhead when compiling in the UFST? I.e. first checking UFST-server then generic? | 09:10.10 |
| chrisl_t530 | norbertj: no, that happens on a per-font basis | 09:10.33 |
| | norbertj: from my testing, UFST and Microtype is slower than Freetype | 09:11.07 |
| | My testing has primarily been with Postscript, but still | 09:11.41 |
| norbertj | I checked only the first few pages of cmp_02_08.pcl for fonttype (and that was BITMAP type only). So I don't understand why the ufst is slower than the freetype build, when only printing download bitmap characters. | 09:12.26 |
| chrisl_t530 | UFST may have a larger overhead at startup, but I doubt that should be significant, especially over a few pages | 09:13.48 |
| | Having said that, the UFST startup overhead should be no worse than the old code | 09:14.22 |
| | norbertj: if these files are only/primarily downloaded bitmap fonts, then I can't see how the change to FAPI would have a significant impact - although, I could be wrong.... | 09:16.20 |
| norbertj | I agree, cmp_02_08 ( 24718 pages) with 914(freetype) is faster than 906(afs?), but with ufst I see something different. We have 906-ufst50 and 914-ufst63 integrated, and then I see 906 with 433 ppm, and 914 with 258 ppm (pages/minute) | 09:24.21 |
| | This is almost 40% down. | 09:25.08 |
| chrisl_t530 | Well, I really don't understand that - neither freetype nor UFST should ever see a bitmap font. They wouldn't know how to handle one, anyway | 09:26.18 |
| norbertj | chrisl_t530: I also don't see the ufst being called, so I'm puzzled as to were this difference comes from. I think I have to dig up the profile again :( | 09:27.58 |
| | profiler | 09:28.06 |
| chrisl_t530 | norbertj: I've only just got the files from peeves (it seems *really* slow today. So I'll do some profiling, and talk with henrys about it | 09:28.59 |
| | norbertj: also, even when UFST *is* being called, I wouldn't expect a slow down of that magnitude..... | 09:30.30 |
| | norbertj: I don't suppose you have smaller a smaller version of cmp_02_08.pcl - maybe just 50-100 pages? | 09:38.09 |
| norbertj | chrisl_t530: I can make one. | 09:47.05 |
| chrisl_t530 | norbertj: as long as it's fairly easy, that would be good - if required, I can hand edit the PCL myself | 09:47.54 |
| norbertj | chrisl_t530: I attached a 50p version on the 695190 (please keep private). | 09:51.04 |
| chrisl_t530 | norbertj: thanks, I've marked it as private | 09:51.58 |
| | Hmm, now I'm wondering if 50 pages is too small :-( | 09:56.02 |
| | norbertj: I can't reproduce a performance difference between freetype and ufst using the 50 page file. And unless my lines are crossed, the full file will take around an hour to complete? | 10:03.36 |
| | norbertj: it looks like cmp_02_08.pcl starts using MT fonts (rather than bitmap) around page 141.... | 10:12.32 |
| norbertj | chrisl_t530: depending on the pc, it takes me (fastest) 750 secs. (12.5 min). | 10:12.55 |
| | I'll make a somewhat larger one that should show a difference. | 10:13.14 |
| chrisl_t530 | norbertj: I was running a profile. I think I'll finish implementing the width caching, and see where that gets us | 10:14.11 |
| norbertj | chrisl_t530: I uploaded a cmp_363p.pcl to peeves (20140428-pclperf). This one gives (compiled for profiling: 914-freetype: 2.5 secs, 914-ufst63: 7.4 secs) | 10:24.30 |
| chrisl_t530 | norbertj: great thanks, I'll grab that now | 10:26.36 |
| | norbertj: it looks like the glyph width cache will get the UFST and FT builds within touching distance of each other..... | 10:46.39 |
| kens | chrisl_t530 : got a strange one here.... | 10:54.54 |
| | In gs_fapi.ps there is a check against EmbedFontObjects | 10:55.12 |
| | WHich calls getdeviceparams, but even with pdfwrite (which is the only place I can see EmbedFontObjects being processed) the result is always 'not present'. | 10:55.46 |
| chrisl | kens: Didn't we change that? I think we sorted FAPI/pdfwrite so they work together | 10:57.40 |
| kens | chrisl I'm sure they work together, its just that this code has no effect, as far as I can see, because the flag is never found | 10:58.15 |
| | Ah, ist not a name, its a procedure.... | 10:58.44 |
| | And it still comes back false...... | 10:59.23 |
| chrisl | kens: then just remove it... we probably just forgot to remove it after we resolved the incompatibilities | 10:59.24 |
| kens | chrisl ,right I'll do that, tahnks | 10:59.33 |
| chrisl | I have to head out for a while - cluster is testing the glyph width cache stuff. Hopefully it will be ready for review when I get back..... | 11:00.38 |
| norbertj | chrisl: FYI I found with the profiler that indeed from ~ page 108 ufst gets called. | 11:01.28 |
| henrys | norbertj: you optimized the dictionaries with binary trees didn't you? | 12:51.01 |
| | norbertj: when looking at your files I noticed something else that will likely make that change unnecessary. | 12:52.08 |
| norbertj | henrys: yes | 12:55.14 |
| henrys | norbertj: but of course it won't hurt to keep it. | 12:56.40 |
| norbertj | henrys: in pldict.c (golden) I implemented a double linked list, so that for freeing you don't have to scan for the correct object in a list | 12:58.20 |
| | henrys: gsmchunk I mean. In our implementation for pldict.c I also added a binary search i.s.o. linear search through a dict. | 13:00.16 |
| henrys | norbertj: oh maybe this is different I notice in your new files looking up items is pretty high up on the profile and I have a fix for that. | 13:01.00 |
| norbertj | henrys: I think I did send you that binsearch. I have a compile-def (USE_BINSEARCH) that enables it. | 13:01.16 |
| | I'm interested ;) | 13:01.26 |
| | henrys: chrisl: FYI the char-cache adding dat Chris did on plfont.c seems to speedup a lot on our controller (cmp_363p.pcl from 14.3s to 8.7s). But I have still to check whether bitmaps are still the same. | 13:13.01 |
| Robin_Watts | paulgardiner_lap: bug 695191 sounds like a bitmap refresh problem to me. | 13:15.44 |
| paulgardiner_lap | Yeah. If we could get hold of a device that shows the problem, we might be able to fix it. | 13:19.20 |
| henrys | norbertj: do you have msvc profiling for the free type vs. ufst runs. I imagine that is different than the other problems from your description | 13:23.43 |
| Robin_Watts | tor8: What version of android do you have on your Samsung Tab ? | 13:25.45 |
| chrisl | norbertj: there are some issues with the width cacheing I'll need to look into | 13:30.49 |
| henrys | chrisl: I wouldn't think it would buy you much in PS and PDF are their frequent calls to get metrics separate from rendering the character, I thought that was a PCL thing. | 13:33.14 |
| chrisl | henrys: I've only done it for PCL | 13:33.37 |
| norbertj | henrys: I have profiling for both, but they are completely different (msvc shows 66% pxl_impl_allocate_interp_instance, 33 % pcl_impl_allocate_interp_instance), (ufst shows 93% pcl_macro_control). | 13:33.53 |
| | I'm puzzled. | 13:33.59 |
| | henrys: perhaps sampling granularity ? | 13:34.30 |
| henrys | chrisl: since it is just PCL I can take it over if you like. | 13:35.52 |
| norbertj | henrys: I compiled with DEBUG=0, TDEBUG=1, DEBUGSYM=1 (pcl6_msvc.mak). Then 'devenv pcl6.exe' | 13:36.02 |
| chrisl | henrys: that's okay, I'll press on - it's nearly there, the think | 13:36.26 |
| henrys | norbertj: We don't have the msvc profiling here, some folks have used sleepy. | 13:40.46 |
| tor8 | Robin_Watts: cyanogenmod 4.something, but I'd have to travel to my parents to pick it up :) | 13:44.02 |
| | Robin_Watts: if I can get the nexus to charge enough to boot I can tell you what version that one has? | 13:44.17 |
| norbertj | henrys: for ufst: : pl_fapi_char_metrics = 56%, for msvc: show_proceed = 49% in which gx_image_cached_char 23% and pl_bitmap_build_char 16% | 13:44.44 |
| Robin_Watts | tor8: We are looking for a honeycomb one (3.1). | 13:46.24 |
| | I think all nexus' are newer | 13:46.30 |
| henrys | norbertj: attaching those profiles to the bug will help us. I want to make sure I'm seeing the same thing on linux | 13:46.38 |
| chrisl | henrys: silly question maybe: given that Postscript, PCL, PXL and XPS all require very similar dictionary type objects, why do we have three completely separate implementations? | 13:50.34 |
| Robin_Watts | Hysterical Raisins! | 13:51.15 |
| norbertj | henrys: attached 2 profile runs. to 695190 | 13:51.17 |
| chrisl | Robin_Watts: I'm wondering if there was a "real" reason, or just general hostility to reusing code in general, and Postscript in particular...... | 13:52.21 |
| white_luis | Hi | 13:52.58 |
| ghostbot | moin moin | 13:52.58 |
| henrys | chrisl: PCL does have symbolic links and "parenting" for dictionaries and for a long time depended on the entries being in a particular order so there always was fear we'd break that stuff if we merged them. I think there should be one implementation | 13:53.57 |
| white_luis | I want to show 2 pages in landscape mode on Android using muPDF. Is there anyone who want to give me some advice. | 13:54.05 |
| norbertj | henrys: can you read the profile files? I can open with vs2012(premium), I don't know if it's possible with a lower VS. | 13:55.06 |
| Robin_Watts | white_luis: Lots of people ask us about that. | 13:55.18 |
| white_luis | Robin_Watts: is there any solution for that | 13:55.44 |
| Robin_Watts | Essentially you need to recode (or modify significantly) the view handling (or maybe the adapter) in the java code. | 13:55.51 |
| henrys | norbertj: I assumed there would be an exchange format like text or at least xml | 13:56.13 |
| norbertj | henrys: I'll check | 13:56.24 |
| chrisl | henrys: it occurred to me a while ago that, had the "core" dictionary types and functions been in the graphics library, it would also have *vastly* simplified the device params implementation | 13:57.13 |
| white_luis | Robin_Watts: Any recommendation for starting point | 13:58.04 |
| norbertj | henrys; what do you prefer: csv or xml ? | 13:58.17 |
| henrys | had a disastrous iOS iPhone update - my phone now will hang up mid conversation and say "slide to power off". | 13:58.19 |
| white_luis | I must implement this feature | 13:58.21 |
| Robin_Watts | presumably you've read the overview of the android classes? | 13:58.21 |
| henrys | norbertj: csv | 13:58.27 |
| Robin_Watts | white_luis: Are you using MuPDF in a commercial product then? | 13:58.43 |
| white_luis | No | 13:58.57 |
| Robin_Watts | within a GPL project then ? | 13:59.07 |
| white_luis | it is not commercial | 13:59.11 |
| Robin_Watts | (AGPL even) | 13:59.13 |
| white_luis | Robin_Watts: Is there anybody to give me some advice about this ? | 14:00.15 |
| Robin_Watts | white_luis: The licensing terms on MuPDF are quite simple. | 14:00.37 |
| | If you want to use MuPDF within a project, you can, provided the entire project is then released under the AGPL. | 14:01.04 |
| | If you don't want to release your project under the AGPL, then you need to get a license from Artifex. | 14:01.32 |
| | (Of course, if you want to use MuPDF privately and never give copies to anyone else, that's fine). | 14:01.58 |
| | But you need to have sorted out licensing before you can distribute it. | 14:02.29 |
| | The developers for MuPDF are all here. The Android code was originally written by me, but was then substatially reworked by paulgardiner. | 14:03.15 |
| norbertj | henrys: I replaced with csv-files | 14:03.25 |
| tor8 | Robin_Watts: oh. maybe if I find a way to restore the samsung tab. | 14:03.49 |
| Robin_Watts | tor8: we'd then have to find a way to get it here :( | 14:04.05 |
| | I had a quick look on ebay to see if there were any obvious cheap 3.1 devices, but it's hard to see any. | 14:04.21 |
| jhabjan | I'm having some trouble with gs piped output... the problem is it seems with the pipe client handle i'm passing to the gs | 14:05.36 |
| white_luis | I couldn't understand the relation with the 2 pages in landscape feature and licensing | 14:05.46 |
| | Robin_Watts: I couldn't understand the relation with the 2 pages in landscape feature and licensing | 14:05.56 |
| kens | jhabjan its believed to work, but we don't use it ourselves so it may have rotted | 14:06.18 |
| Robin_Watts | white_luis: Well, if you've got a commercial license that often comes with a certain amount of support. | 14:06.34 |
| white_luis | May I use mupdf in my project and submit to google play | 14:06.42 |
| Robin_Watts | Are you going to give all your sourcecode away ? | 14:07.00 |
| kens | "Make all your source code available" | 14:07.15 |
| jhabjan | kens: the issue is if I call the CloseHandle function to close the write handle to the pipe too early, gs can't connect to it, and if I close it too late it says invalid handle.. | 14:07.23 |
| white_luis | No I wont give the sourcecode | 14:07.24 |
| Robin_Watts | Then, no, you can't use MuPDF without a commercial license. | 14:07.34 |
| kens | jhabjan, not really my field, I haven't tried using the named pipe, what do you mean by closing it 'too late' ? | 14:08.15 |
| henrys | chrisl: my memory is fuzzy but I think PCL may need to blow away that cache from time to time. I can look at the code after the meeting. | 14:08.22 |
| white_luis | All codes will be available that are related with mupdf reader | 14:08.55 |
| chrisl | henrys: I think it's working now - I missed that get_char_width() returning "1" had a special meaning | 14:09.15 |
| norbertj | henrys: have to go. I will check later. I blow away the cache in pcl_font_reset(permanent) I think. | 14:09.17 |
| white_luis | But not all of our project | 14:09.20 |
| jhabjan | kens: too late - after reading from the pipe is done | 14:09.37 |
| kens | Hmm, I'm surprised that's a problem | 14:09.51 |
| Robin_Watts | white_luis: You need to go and read the GNU AGPL (or get legal advice) | 14:09.56 |
| norbertj | henrys: when switching between pcl/pxl also cache is removed I think. | 14:10.00 |
| | bye | 14:10.05 |
| Robin_Watts | Everything that gets linked with mupdf must have the source code released (unless you have a commercial license) | 14:10.54 |
| white_luis | Robin_Watts: is there anyone about commercial licensing | 14:11.09 |
| Robin_Watts | You can mail sales@artifex.com and speak to scott. | 14:11.36 |
| chrisl | henrys: the only time the widths cache in the old code is emptied is when it's full..... | 14:12.02 |
| Robin_Watts | He'll ask you lots of questions, many of which won't apply. Just answer as best you can. The more info you give him, the better he can tailor his licensing proposal to your needs. | 14:12.12 |
| henrys | chrisl: okay | 14:12.37 |
| white_luis | Ok. I m mailing him | 14:12.49 |
| | If I have commercial license, What kind of support I got | 14:13.29 |
| ray_laptop | white_luis: we have both supported and unsupported mupdf licensees, but we prefer that our customers get support | 14:14.04 |
| Robin_Watts | As ray_laptop says, it depends on the license. | 14:14.24 |
| ray_laptop | white_luis: we want our customers to be happy, and when they don't get support and have to wait behind supported customers for a bug fix or to get help, then they aren't happy | 14:15.05 |
| | white_luis: I don't know about mupdf customers, but we have several ghostscript support only users, that could get by with operating under the AGPL, but want the extra | 14:16.08 |
| white_luis | If I get commercial license ? What kind of help you gave me about 2 pages in landscape mode feature ? | 14:18.46 |
| ray_laptop | white_luis: for most supported customers, it's unlimited support. We like it best that way since us engineers don't have to keep track of hours spent, which is a pain. | 14:19.22 |
| Robin_Watts | white_luis: Most customers tend to do integration etc themselves. | 14:19.48 |
| | but we do NRE work too. | 14:19.59 |
| | certainly we'll be happier to spend time explaining exactly what needs to be changed etc to a supported customer than to someone who is potentially using MuPDF without a proper license. | 14:21.03 |
| ray_laptop | white_luis: and we accept 'enhancement' requests (see our bug tracker) but there is no promise about when they get done, Thus the development NRE that Robin mentions. | 14:21.16 |
| | strong "Santa Ana" winds today, here. Dry, hot, windy air, along with the gusty winds. Not the best thing for my eye :-( | 14:23.03 |
| henrys | meeting in 5 minutes | 14:24.14 |
| kens | Ray in triplicate | 14:27.15 |
| chrisl | We're going to be overrun by an infinite number of Rays...... | 14:29.04 |
| Robin_Watts | writing the complete works of shakespeare? | 14:29.18 |
| | :) | 14:29.22 |
| kens | If we give them a keyboard each we cna get better software | 14:29.25 |
| | One of our Rays ismissing | 14:30.24 |
| henrys | must be the wind | 14:30.46 |
| | blowing his keys | 14:30.56 |
| ray_laptop | sorry. network a bit flaky | 14:30.57 |
| henrys | ray_laptop: same thing here we got these nasty downslope winds. | 14:31.51 |
| mvrhel_laptop | good morning | 14:32.58 |
| kens | Morning Michael | 14:33.06 |
| henrys | so for the meeting it is suggested everyone join GhostDocs on Skype, you don't have to participate just join, so if you are called into action you'll have the logs and folks won't have to "reexplain" what is going on. | 14:33.30 |
| | chrisl, tor8 and ray_laptop need to get hooked up I think | 14:34.17 |
| chrisl | Do we need to be invited to join? | 14:34.43 |
| kens | is incurably nosy, and already there | 14:34.49 |
| Robin_Watts | I just added you all. | 14:35.06 |
| ray_laptop | henrys: I usually don't have Skype open. Do I have to (I get all kinds of pop-ups from people I don't know) | 14:35.31 |
| Robin_Watts | It doesn't matter if you don't run skype. | 14:35.47 |
| | By adding you now, you get access to all the logs. | 14:35.55 |
| | (all the logs from this point forwards rather) | 14:36.09 |
| ray_laptop | Robin_Watts: so I don't need to "join" now -- I'm already there ? | 14:36.12 |
| Robin_Watts | ray_laptop: I believe so. | 14:36.20 |
| ray_laptop | Robin_Watts: How to I see the logs ? | 14:36.29 |
| henrys | mvrhel_laptop so what of gsview release? Do we hold off until next release? | 14:36.31 |
| Robin_Watts | ray_laptop: Start Skype, look at the group. | 14:36.44 |
| ray_laptop | (search for GhostDocs says "no results" | 14:36.49 |
| henrys | mvrhel_laptop: September | 14:36.53 |
| Robin_Watts | Nothing has been said since you joined. | 14:37.01 |
| henrys | ray_laptop: I hate Skype to and we will try and keep as much discussion as possible here. | 14:37.19 |
| mvrhel_laptop | henrys: I am very close. I am beating on it to shake out any bugs. Finding a few here and there. If we want good testing by everyone it may be best to do a real release in Sept. but a beta now | 14:37.33 |
| | or shortly that is | 14:37.36 |
| kens | that woudl give me time to review current gxview (5.0) and compare | 14:38.13 |
| henrys | mvrhel_laptop: It looks pretty nice - featureful ... | 14:38.15 |
| mvrhel_laptop | henrys: yes. I really wanted to make it something that people would find useful | 14:38.37 |
| marcosw_ | sorry I'm late. | 14:38.53 |
| henrys | mvrhel_laptop: should we make a separate docs page in gs/docs? | 14:39.08 |
| | or completely separate | 14:39.22 |
| | I guess | 14:39.24 |
| ray_laptop | Robin_Watts: I'll ask after the meeting about Skype. | 14:39.58 |
| henrys | we could try and buy gsview.com thoughts? | 14:39.59 |
| chrisl | Unless we're putting gsview in the ghostpdl repo, I think we keep the docs separate - especially as it's mostly mupdf anyway | 14:40.09 |
| henrys | chrisl: yea I agree | 14:40.22 |
| tor8 | henrys: get jbig2dec.com while you're at it... I've been meaning to ask chrisl if we should do that release now. | 14:40.36 |
| mvrhel_laptop | yes. separate would be good. gsview.com might be nice to have | 14:41.03 |
| henrys | tor8: I don't know if I want anyonee to know about jbig2dec ;-) | 14:41.05 |
| mvrhel_laptop | I see some chinese group is sitting on it | 14:41.26 |
| chrisl | <sigh> I wonder needs done for a jbig2dec release...... | 14:41.30 |
| Robin_Watts | buys jbig2dec.com quickly and flips it to Miles for $1000 :) | 14:41.58 |
| tor8 | chrisl: I suspect just tagging and making a tarball of what we have should be fine | 14:42.01 |
| mvrhel_laptop | Robin_Watts that is funny | 14:42.16 |
| tor8 | chrisl: no binary releases or anything like that, just a source tarball | 14:42.28 |
| chrisl | tor8: I should probably find a previous release and see what's in it | 14:42.32 |
| henrys | mvrhel_laptop: okay I'll talk to miles about gsview.com then you can just organize the product release as you see fit with our help if you need it. | 14:43.07 |
| mvrhel_laptop | henrys: ok that sounds good. | 14:43.44 |
| henrys | marcosw: recent reports from norbert show we did miss a big performance hit. We need to have a few long playing jobs that check for time and memory I think. These were all 1000+ page text jobs | 14:44.47 |
| Robin_Watts | henrys: Is the performance hit ufst only? | 14:45.14 |
| henrys | Robin_Watts: nope we should have hit it with the switch to free type for pcl | 14:45.38 |
| | in addition to the ufst, but I suppose we should do a ufst test as well | 14:46.13 |
| chrisl | henrys: really? I thought we were about comparable with freetype | 14:46.21 |
| ray_laptop | this is PCL only ? | 14:47.05 |
| henrys | chrisl: I am saying there should have been a detectable slowdown going from artifex -> free type due to how metrics are handled | 14:47.08 |
| | ray_laptop: yes | 14:47.56 |
| chrisl | henrys: there was, and we did know about it, Then I added optimisations that I thought got us back in the same ballpark | 14:48.02 |
| tor8 | freetype has two types of metric functions, accurate (that decodes the glyph) and fast (just looks at the metrics tables). | 14:48.21 |
| | not sure which ones we use in gs | 14:48.35 |
| chrisl | We use the that decodes the glyph as we generally render the glyph at the same time | 14:48.57 |
| henrys | tor8: well we used a cache to solve it because the ufst needs it anyway. | 14:49.16 |
| chrisl | henrys: I could only find the caching for UFST, it didn't cache for the AFS code | 14:49.46 |
| marcosw_ | henrys: we can add some long jobs to tests_private/performance/pcl, however testing with ufst is going to be more work. | 14:50.08 |
| chrisl | I'm really stunned at how slow UFST is in these cases, frankly | 14:50.44 |
| henrys | chrisl: it didn't need to cache for the AFS code because it pulled the metrics from the font file | 14:51.03 |
| | chrisl: why you are effectively rendering every character without caching to get the metrics it should be dog slow | 14:51.30 |
| chrisl | henrys: we should get the glyph metrics from the glyph cache, and not have to render every time..... | 14:52.18 |
| henrys | chrisl: I had an argument years back with jim doolittle that they needed a lightweight mechanism for getting metrics but he wouldn't do it hence the cache. | 14:52.58 |
| chrisl | henrys: what I don't understand is why UFST is *so* much slower than freetype for this | 14:53.32 |
| | henrys: and, FWIW, I suspect there isn't a way to to a light weight solution with the MT font format | 14:54.08 |
| henrys | chrisl: maybe | 14:54.36 |
| chrisl | henrys: but anyway, my understanding was that with freetype, the speed was similar to the pre-fapi code | 14:55.16 |
| henrys | anything else for the meeting? | 14:55.20 |
| | chrisl: no norbert's original report included pre fapi vs current - no ufst. | 14:56.15 |
| chrisl | henrys: which "original report"? Not 695190 | 14:56.59 |
| henrys | ray_laptop: it is PCL I'm just worried we aren't catching stuff generally but it seems we are as chrisl noted | 14:57.14 |
| | so let's call the meeting adjourned. and on to ghostdocs | 14:58.53 |
| chrisl | Right, so I'm down to one oddity with the new cache code..... | 15:00.12 |
| henrys | chrisl: I went from the but straight to profiling and saw free type metrics were beating us up and proposed the cache be added back. I did't write down times but I recall there being some substantial difference | 15:00.46 |
| | s/but/bug | 15:00.54 |
| chrisl | henrys: well, that's odd, given I did check performance times after I added the speed improvements last year..... | 15:02.07 |
| henrys | paulgardiner_lap, Robin_Watts it seems like we should incorporate all the SOT customers into the customer list. | 15:02.36 |
| Robin_Watts | henrys: Yes. That would remove most of the need for skype. | 15:02.51 |
| henrys | and I think it would help with priorities. | 15:03.21 |
| paulgardiner_lap | Then we refer by number presumably | 15:03.23 |
| Robin_Watts | how would it help with priorities? | 15:03.51 |
| henrys | Robin_Watts: I am hoping miles will put them in the bins we have now. | 15:04.22 |
| Robin_Watts | oh. I see, gotcha. | 15:04.33 |
| | (For the benefit of joseph/pedro then, we have a customer list, which lists customers by number, broken into 'high', 'medium', 'low' support etc) | 15:05.22 |
| henrys | mvrhel_laptop: how is your sot experience so far? | 15:05.33 |
| pedro__ | nods - sounds sensible | 15:05.39 |
| Robin_Watts | (And then we can talk on here by saying "Customer 801 wants..." | 15:05.40 |
| mvrhel_laptop | henrys: you mean with skype? | 15:06.02 |
| henrys | mvrhel_laptop: no your working on an sot bug | 15:06.44 |
| mvrhel_laptop | I agree that having all the customers in one group would make sense for the reasons that you mention | 15:06.46 |
| Robin_Watts | We got it so that it was building on mvrhel's machine. I don't know how much more he had the stomach for after that :) | 15:06.47 |
| henrys | mvrhel_laptop: your the guinea pig | 15:06.53 |
| | s/your/you're | 15:07.12 |
| | pedro__: looks like good is coming along okay? I saw the message from richard. | 15:07.56 |
| pedro__ | henrys: yes, at least that last link to the partner portal gives a bunch of docs describing the missing pieces of the puzzle... | 15:08.41 |
| henrys | chrisl: it just came to mind - did you add the improvements after 9.06? | 15:08.42 |
| | chrisl: I'll give you times when I finish this meeting | 15:09.05 |
| ray_laptop | I turn Joann's list into text, then use: "grep -i $1 c:/artifex/business/Customer_Support.txt" to quickly find customers by number or name | 15:09.19 |
| mvrhel_laptop | henrys: so I just grabbed a bug that we have when rendering our own power point | 15:09.20 |
| pedro__ | looks like we can register a com.artifex.sot app ID and keep it independent of the ios/android bundle IDs (which is nice) | 15:09.30 |
| mvrhel_laptop | in an attempt to see if I could step through the code and try to understand what is going on | 15:09.36 |
| pedro__ | I'm going to push a bit harder to see if we can get the 1.4 SDK version verified first - still feels like wwe have some learning to do on the whole setup and it'd be good to get the existing iOS app available first | 15:10.32 |
| chrisl | henrys: the switch to FAPI didn't happen until 9.08 - I added speed improvements for PCL between 9.10 and 9.14 | 15:10.32 |
| mvrhel_laptop | I am up and running but I need to read through some of the docs that jogux pointed me to | 15:10.41 |
| henrys | mvrhel_laptop: your experience is the interesting one ⦠you have years of indoctrination | 15:11.03 |
| paulgardiner_lap | We still have a problem with the G version for iOS showing a blank screen after authentication, which I'm banging my head against. Progress on that is slow but maybe getting somewhere | 15:11.12 |
| henrys | s/you/you don't | 15:11.12 |
| pedro__ | they seem to be pushing for current SDK though, and it may be that we will have interop problmes with current versions of the GoodEnterprise/GoodAccess apps | 15:11.19 |
| mvrhel_laptop | henrys: yes | 15:11.21 |
| pedro__ | henrys: in terms of the app testing/verification, do you want to be the point of contact or would you like me/paulgardiner to do that? | 15:12.27 |
| henrys | pedro__: I think paulgardiner_lap is the best choice but I'd like a cc: | 15:12.59 |
| pedro__ | nods | 15:13.07 |
| henrys | paulgardiner_lap may feel differently ;-) | 15:13.22 |
| paulgardiner_lap | henrys: no, that sounds good. | 15:13.39 |
| Robin_Watts | henrys: It seems that picsel have been releasing from a release branch, and developing on master for quite a while. | 15:13.52 |
| | The two have diverged more than we'd like. | 15:13.58 |
| | I've been trying to pull the fixes from the branch back onto master so that we can continue working from there. | 15:14.23 |
| | and that's been taking longer than I'd have liked, but I think we need to do it. | 15:14.35 |
| paulgardiner_lap | jogux has managed to recreate some of the old picsel network on one of his machines, so we have the old twiki running now, and to some extent ATS (although I don't know to what extent the latter) | 15:14.47 |
| Robin_Watts | and I have customers asking awkward questions too. | 15:14.54 |
| henrys | Robin_Watts: and we are still going along without regression tests? | 15:15.05 |
| Robin_Watts | henrys: The plan is that when jogu gets ATS up and running, we'll push through each commit so far and make sure that there is nothing catastrophic there. | 15:15.37 |
| jogux_mac | it turned out that the ATS VMs we have weren't in the same state we were expecting, as for an unknown reason they were taken before the setup was finished :-( | 15:15.39 |
| henrys | Robin_Watts: it would be nice to check each change as you go along right? | 15:15.42 |
| Robin_Watts | henrys: Ultimately that's the goal. | 15:15.51 |
| jogux_mac | I'm making progress though. | 15:16.05 |
| Robin_Watts | The branch -> trunk cherry picks are on my personal repo so far. | 15:16.08 |
| jogux_mac | we do have the picsel mail system, bugzilla, review system and twiki fully running I believe. | 15:16.44 |
| Robin_Watts | That's good news! | 15:17.10 |
| henrys | jogux_mac: once set up, what is the turn around time going to be like for a single change? | 15:17.36 |
| | jogux_mac: to regression test a single change | 15:17.55 |
| paulgardiner_lap | jogux_mac: the ATS status page was reporting that it had completed some jobs a day or so ago. Is that total fiction? | 15:18.06 |
| Robin_Watts | henrys: depends how many nodes we throw at it. | 15:18.18 |
| jogux_mac | the next things on my list are : try importing a initial ATS database that's been found in CVS (which should be much more complete than the one on the current server), try getting tgv ath to run, try and speed things up (mostly with ramdisks), improve the linux client setup, look at getting it talking to git, and finishing installing necessary things on build clients. plus more things. | 15:18.56 |
| Robin_Watts | My memory was of it taking about 20 minutes at Picsel. | 15:19.09 |
| jogux_mac | paul : that did happen - I've done an android build and all variants of runtests, though two of the variants of runtests failed. | 15:19.15 |
| henrys | Robin_Watts: I thought for comms purposes we were maxed at marcosw_ garage | 15:19.17 |
| Robin_Watts | henrys: I suspect the uber servers in marcosw's garage are MUCH more powerful than anything picsel had. | 15:19.47 |
| | so being restricted there need not be a showstopper. | 15:19.57 |
| pedro__ | Robin_Watts: that sounds about the right ballpark; depends on the number of UE2 tests we run now | 15:20.07 |
| jogux_mac | henrys : it remains to be seen. the machine I'm setting them up on is a 2.3GHz quad core 4th gen intel thing, currently I'm hugely maxing out the single disc, and the speed is dire. | 15:20.10 |
| Robin_Watts | henrys: We can possibly bring in other nodes using ssh tunnels given time. | 15:20.15 |
| jogux_mac | ie. it's I/O bound (hence ramdisks) | 15:20.33 |
| Robin_Watts | oh yes. This is all currently happening local to Jogu, of course. | 15:20.36 |
| jogux_mac | I don't know how my shiny new fanless server compares to marcos's machine(s) :) | 15:20.55 |
| pedro__ | are we keen to keep all of this on local servers or would we consider using AWS or similar? | 15:21.15 |
| henrys | jogux_mac: oh so they are quiet? I'm looking for something like that. | 15:21.31 |
| Robin_Watts | AWS costs add up. | 15:21.33 |
| pedro__ | nods | 15:21.43 |
| jogux_mac | henrys : if I hadn't added the 3TB spinning disc it would be *silent* | 15:21.49 |
| henrys | jogux_mac: have a link? | 15:22.20 |
| jogux_mac | henrys : http://www.quietpc.com/sys-a470 is roughly what I have. (they have desktop equivalents) | 15:22.21 |
| | henrys : http://www.quietpc.com/systems for the full list. | 15:22.35 |
| | don't think they ship to the US, but hopefully you can find a supplier for the same components. | 15:22.51 |
| henrys | so it looks like ghostdocs is moving along, anything I should pass on to Miles, I meet with him right after this? | 15:23.09 |
| pedro__ | Robin_Watts: I was partly thinking about the ability to provide ATS to SOT customers as a testing service in future | 15:23.43 |
| Robin_Watts | henrys: At the moment, he's signed 5 customers and has another 3 on the hook. | 15:23.44 |
| | We are expecting to ship to all of them in September. | 15:24.00 |
| | experience suggests that the first build we do for any new customer will have a problem. | 15:24.15 |
| henrys | Robin_Watts: so expect to ship to them in August | 15:24.42 |
| | ;-) | 15:24.48 |
| Robin_Watts | so I suspect that when we take a new customer on, we should (pretty) immediately do a build for them, just to get the gremlins out. | 15:24.51 |
| | otherwise we're going to be chasing bugs for 8 customers all at once. | 15:25.10 |
| pedro__ | henrys> we have Good control/proxy servers set up locally as well and can authenticate our Good apps against them, so Paul is trying to get the existing iOS build with the v1.4 SDK working and I'm part way through the android app upgrade to new APIS so definitely progress albeit slower than we'd like | 15:25.26 |
| Robin_Watts | So, when Miles takes on a customer, can he give us contact details for them so we can (at our leisure) contact them and send them a build for them to check ? | 15:25.43 |
| | i.e. it'll spread our workload out. | 15:26.14 |
| henrys | Robin_Watts: I'll ask him that, yes | 15:26.14 |
| jogux_mac | I don't know if the information is already in the customer sheet, but exactly what various of SO they're getting and for which platform(s) might be useful info | 15:27.13 |
| | s/various/variant/ | 15:27.27 |
| henrys | jogux_mac: I wonder if we shouldn't start a completely separate customer list perhaps starting from the spreadsheet you used at picsel | 15:28.05 |
| Robin_Watts | jogux_mac: It should be in the Release_Tracking_Sheet.xls | 15:28.17 |
| | (and by doing test builds for them as they join, it would end up in the Twiki) | 15:28.30 |
| jogux_mac | robin : well, once we've done a release, I guess so yes :-) | 15:28.32 |
| jogux_mac | nods | 15:28.37 |
| | henrys : the picsel release tracking spreadsheet has been replaced by http://twiki.ghostscript.com/do/view/GhostDocs/CustomerReleases btw | 15:29.05 |
| paulgardiner_lap | We could add a support-level column to that | 15:29.44 |
| Robin_Watts | The problem with that is that support level changes over time. | 15:30.06 |
| paulgardiner_lap | And Artifex customer number | 15:30.07 |
| jogux_mac | paul : ideally not, given there's multiple entries for each customer. | 15:30.16 |
| paulgardiner_lap | Oh yeah. That's releases isn't it | 15:30.28 |
| Robin_Watts | (companies upgrade/downgrade support, forget to pay etc :) ) | 15:30.36 |
| henrys | okay thank jogux_mac, for now I'll just have miles add customers to our other list so we have numbers and priority bins, then we'll cross reference to the other docs. | 15:30.54 |
| Adam___ | Hi, anybody can help me with gswin, please? | 15:31.03 |
| jogux_mac | robin : :) | 15:31.22 |
| Robin_Watts | henrys: We should ask joann to include Jogu/Pedro on the distribution list then. | 15:31.23 |
| | Adam___: Don't ask to ask, just ask :) | 15:31.41 |
| chrisl | Adam___: were you here yesterday? | 15:32.12 |
| henrys | okay I'm exceeding meeting threshold ;-) anything else? | 15:32.44 |
| jogux_mac | what would be thoughts on me / pete getting involved with customer contact? The customer that's complaining about all sorts of iOS crashes it might potentially be helpful if I got more directly into the conversation. | 15:33.00 |
| Adam___ | Hi chrisl! Yesterday's problem solved! Solution: place input and output filenames at the END of command line :) | 15:33.12 |
| jogux_mac | (still including Paul and whoever else in the loop of course) | 15:33.16 |
| chrisl | Adam___: Excellent! I just spotted that a few moments after you left! | 15:33.36 |
| pedro__ | Robin_Watts: minor distraction> I just got some juice into one of our old samsung tabs and its running 3.2 if that's any use? | 15:33.54 |
| Robin_Watts | pedro__: OOh, that might be. | 15:34.06 |
| henrys | ray_laptop: did you get a credit card from miles to get mujs.com - it might go faster if you get gsview.com? | 15:34.09 |
| Adam___ | So it works, but i have another problem. White areas from PDF file after conversion are not white and it is paper white from destination profile - fine! But transparent areas are NOT converted and remains white (C=0, M=0, Y=0, K=0). I would like to have theese areas converter to paper white too. No idea how to do this. | 15:37.02 |
| | * converted (sorry) | 15:37.49 |
| chrisl | Adam___: TIFF doesn't have transparent areas | 15:38.16 |
| Adam___ | I mean transparent areas in PDF input file. | 15:38.52 |
| Robin_Watts | That would suggest that the fillpage is coming out as a different type of white ? | 15:39.32 |
| | or that the fillpage isn't happening? | 15:39.40 |
| ray_laptop | mvrhel_laptop: I found that the check for transparent src_alpha was bogus. It is inverted prior to where the check was :-( I needed src_alpha == 255 | 15:39.48 |
| kens2 | is waiting for the logs to catch up so I can see what's being discussed :( | 15:39.53 |
| ray_laptop | henrys: no, Miles used his credit card | 15:40.23 |
| chrisl | Robin_Watts: the erasepage "color" won't have had the input profile applied | 15:40.28 |
| | since we don't have the input profile at that point | 15:40.44 |
| Robin_Watts | That sounds... bad? | 15:40.46 |
| kens2 | Hmmmm in that case how do untouched areas come out correctly ? | 15:40.52 |
| Robin_Watts | kens2: According to Adam___, they don't. | 15:41.10 |
| Adam___ | I am converting InDesign PDF files to TIFF for proofing purposes, so white and transparent areas in layout should be treated the same, as paper. | 15:41.11 |
| kens2 | Robin_Watts : I thought they did, it was only areas underlyign transparent objects that don't | 15:41.27 |
| chrisl | I'm assuming "White areas from PDF file" are areas that are drawn white in the PDF | 15:41.37 |
| kens2 | I think it would be good to see a sample file, to prevent confusion | 15:41.55 |
| chrisl | and what he means by "transparent areas" are really "unmarked areas" | 15:42.06 |
| Robin_Watts | Adam___: Can you make a PDF available that shows the problem please? | 15:42.08 |
| kens2 | white areas cxan be white because they are untouched, or because they are drawn white | 15:42.10 |
| Adam___ | Let me clear situation please. | 15:42.29 |
| Robin_Watts | kens2: To quote from earlier: "White areas from PDF file after conversion are not white and it is paper white from destination profile - fine! But transparent areas are NOT converted and remains white (C=0, M=0, Y=0, K=0)." | 15:42.48 |
| kens2 | ROq I did read that, but 'white area' is very ambiguous | 15:43.09 |
| | as is 'transparent area' | 15:43.15 |
| ray_laptop | fillpage happens BEFORE the pdf14 compositor exists | 15:43.53 |
| kens2 | Right, but what about the ICC profile ? | 15:44.11 |
| mvrhel_laptop | ok i am back | 15:44.21 |
| ray_laptop | and the 'put_image' when the pdf14 compositor is popped doesn't write outside the 'dirty' box | 15:44.28 |
| kens2 | I presume teh compositor assumes hte page is white | 15:44.45 |
| | I still think a simple exmaple woudl be best | 15:45.01 |
| mvrhel_laptop | ray_laptop: ah ok | 15:45.03 |
| ray_laptop | kens2: the compositor assumes the page is transparent | 15:45.06 |
| chrisl | ray_laptop: it must have a background color to blend onto? | 15:45.38 |
| kens2 | Hmm, is that correct ? I'd have expecgted it to compose with white | 15:45.45 |
| ray_laptop | but when pdf14_put_image "flattens" the page, it blends with the underlying page color | 15:46.01 |
| mvrhel_laptop | yes. at the final put image | 15:46.09 |
| kens2 | So what if we have a ICC profile that moves 'white' to something other than 0 0 0 0 cmyk ? | 15:46.35 |
| ray_laptop | kens2: that's in gx_blend_image_buffer | 15:46.40 |
| Adam___ | I have layout made in InDesign. I placed only one object: white square in the middle. This square does NOT fit all layout area. Then i export this to PDF file. In PDF i have white square and TRANSPARENT area around it. For printing purposes it make no difference, because it means NO INK. But for proofing purposes ALL area of my layout shoud be not whit to simulate paper color. Now after conversion to TIFF i have paper color on my | 15:46.52 |
| kens2 | Adam___ : It would help a lot to see the file and look at its construction, that's much clearer than a text explanation | 15:47.18 |
| mvrhel_laptop | you are going to have to submit the file and the command line | 15:47.27 |
| | and your output and expected output | 15:47.39 |
| Adam___ | OK, give me 5 minutes to make these files, ok? | 15:47.52 |
| ray_laptop | Adam___: and your destination device ICC profile if it's not the standard one | 15:47.58 |
| mvrhel_laptop | right | 15:48.08 |
| ray_laptop | Adam___: or proofing profile, if you are using one, I guess | 15:48.42 |
| ray_laptop | never dug into proofing profiles | 15:48.57 |
| Adam___ | my destination profile is not standard, but it may be PSO_LWC_Improved_eci - no matter | 15:49.06 |
| Robin_Watts | pedro, jogux, paulgardiner_lap: I have some crap hacks here that make windesktop-sot build on the branch. | 15:49.33 |
| | seems to run too. | 15:49.36 |
| | I don't plan to commit them, but if anyone ever wants to do the same I can share. | 15:49.47 |
| jogux_mac | would be tempted to commit, unless there's a high chance of them breaking something. | 15:50.25 |
| pedro__ | should only really affect the dev builds I'd guess | 15:50.56 |
| Robin_Watts | jogux_mac: "crap hacks" :) | 15:51.47 |
| | And it seems the build i've just done is not showing arabic (or other) fonts. | 15:52.24 |
| jogux_mac | robin: hm. :) I might be tempted to put them onto a branch perhaps then. dunno. | 15:52.36 |
| Robin_Watts | I have them on a local branch. | 15:52.53 |
| | which I will keep rebasing up the release branch. | 15:53.06 |
| | like I say, if anyone else ever needs them I'll share. | 15:53.20 |
| jogux_mac | nods | 15:56.34 |
| Adam___ | Files are ready via WeTransfer: https://www.wetransfer.com/downloads/cffacc2670b80f4a75218d509e7cbed420140429160810/a0cb411da29821bb30c5cab9241c59e120140429160810/714f89 | 16:09.59 |
| kens2 | Looks to me simply like the untouched areas (which are painted white with erasepage) are not being colour anaged | 16:12.07 |
| | THought hte colour bars at the top appear to be too pale also, in the grays | 16:12.40 |
| henrys | ray_laptop: we're having gusts of 60 mph here today, always make for an interesting run. | 16:13.47 |
| kens2 | One for mvrhel_laptop to look at | 16:13.58 |
| Adam___ | White field in color bar is white object, so it is NOT transparent in PDF | 16:14.28 |
| kens2 | What you refer to as transparent is in fact 'untouched' I believe. You need to be careful what you describe as 'trnsparent' as that's a different thing in PDF. | 16:15.12 |
| Adam___ | Transparent in PDF i mean no object on the layout. When you rasterize that PDF in Photoshop you can get really transparency. | 16:16.31 |
| kens2 | WHich is 'untouched' in realiyt, not 'transparent' which has a specific meaning in PDF and is not the same as 'untouched' or 'unpainted' if you prefer | 16:17.07 |
| Adam___ | OK, sorry for mess in my language :) | 16:17.55 |
| | I mean unpainted of course. | 16:18.12 |
| kens2 | As far as I cna tell wihtout simplifying the file, the unpainted areas are not being colour managed. These are coloured in the 'erasepage' whcih happens implicitly at the start of every new page of content. PDF, like PostScript, erases to white normally. It seems like the erasepage is just not applying the ICC profile. So defintiely one for Micahel I would say. | 16:19.26 |
| chrisl | kens2: not applying the device profile? | 16:19.58 |
| kens2 | Yeah that's what I htink | 16:20.05 |
| chrisl | Eek, that's bad :-( | 16:20.14 |
| kens2 | But its curious that the grey ramp is also incorrect | 16:20.20 |
| | So maybe that's not the case. Beyond me anyway :-) | 16:20.39 |
| chrisl | I thought it was maybe in input profile in the PDF | 16:20.57 |
| kens2 | THere's a *huge* profile in the PDF | 16:21.11 |
| | Ah but its an outputintent profile | 16:21.56 |
| | This being a PDF/X file | 16:22.06 |
| Adam___ | Gray ramp is not color managed. It is strange. | 16:22.27 |
| | But color ramp IS color managed :) | 16:23.12 |
| mvrhel_laptop | If you can open a bug I will try to take a look at this during the week | 16:23.16 |
| | it is an interesting issue | 16:23.44 |
| Adam___ | If you want me to make any test files just ask: adam.kulikowski@letrabit.pl | 16:24.41 |
| kens2 | Adam___ : you need to open a bug report so that Michael gets it assigned to him | 16:25.06 |
| Adam___ | I never did bug report but i will try :) | 16:25.40 |
| kens2 | Its pretty easy, just sign up with Bugzilla for an account, then add a new bug. Make the product Ghostscript and the component 'colour management. Attach the PDF file and state the command line you are using. THat's pretty much it | 16:26.32 |
| kens2 | notices the time! | 16:26.57 |
| | Godnight all | 16:27.06 |
| | Or even goodnight | 16:27.14 |
| Adam___ | Thank you for help! | 16:27.15 |
| mvrhel_laptop | Adam___: http://bugs.ghostscript.com | 16:37.14 |
| Adam___ | Yes, i am writing bug report now. | 16:39.00 |
| | And i found why white box in gray ramp is not color managed. | 16:40.21 |
| | This white box is set as grayscale=0, while white box in the middle of the layout is C=0, M=0, Y=0, K=0 | 16:41.32 |
| henrys | chrisl: norbert's Kopia_av* file 10 sec (head) 6 sec (9.06) - not ufst | 16:44.53 |
| | jogux_mac: quietpc.com look like UK prices to me. | 16:45.36 |
| Robin_Watts | ray_laptop: So, Skype... Are you seeing the group there now ? | 16:45.37 |
| | henrys: quietpc.com is a UK site. | 16:46.17 |
| jogux_mac | henrys : yeah... I think they will ship internationally, but you can probably find the same components from a US supplier. I built the system up myself from components, it was pretty easy. | 16:46.34 |
| mvrhel_laptop | Adam___: ok. I will take a look this week. | 16:46.37 |
| henrys | jogux_mac: I could do that and sell them to quietpc.com and they'd still make a profit ;-) | 16:47.36 |
| ray_laptop | Adam___: gray colorspace _is_ managed (AFIAK), but it uses the gray input profile instead of the CMYK input profile | 16:48.05 |
| Robin_Watts | henrys: Sadly, in the UK, we pay in pounds what you pay in dollars for a lot of kit. | 16:48.23 |
| ray_laptop | mvrhel_laptop: let me know if I don't understand it correctly | 16:48.32 |
| jogux_mac | henrys: hehe :-) | 16:48.38 |
| | 20% sales tax in the UK is very annoying. | 16:48.48 |
| mvrhel_laptop | yes. everything should be color managed | 16:48.50 |
| henrys | jogux_mac: so these are just water-cooled setups I assume | 16:48.55 |
| mvrhel_laptop | ray_laptop: ^^ | 16:48.56 |
| jogux_mac | henrys : nope - passive air cooled | 16:49.05 |
| | I wouldn't go near water cooling :-) | 16:49.21 |
| henrys | jogux_mac: oh even the cpu ⦠huh | 16:49.24 |
| jogux_mac | there's some big heat pipes for the cpu cooler :-) | 16:49.32 |
| Robin_Watts | partly cos of import taxes into the EU, partly because of the VAT, partly because of longer warranties here, but mostly just because. | 16:49.33 |
| jogux_mac | (bigger still if you pick the higher end cpu :-) ) | 16:49.53 |
| Robin_Watts | I have a zalman cooler on my machine here (figure of 8 heatpipes with a large slow fan). | 16:50.44 |
| Adam___ | ray_laptop: You are right! It may be grayscale default profile. I will check it out. Thanks. | 16:50.53 |
| ray_laptop | Robin_Watts: that's what I have on peeves, too. But while it's reasonably quiet, it isn't silent | 16:51.25 |
| Robin_Watts | ray_laptop: Indeed. But the noisiest thing in mine is... hard to pin down, I don't think it's the CPU fan. | 16:52.01 |
| | More likely to be the 2 huge fans on the gfx card. | 16:52.13 |
| jogux_mac | when it was just an SSD, several times I was convinced the machine was powered off when it wasn't :-) | 16:52.17 |
| Adam___ | Thank you very much for help, and you are doing outstanding job! Ghostscript is really good software! Bye then! | 16:52.23 |
| chrisl | henrys: on my machine Kopia_av_00003.pcl with 9.06 takes 6.075 seconds, with the changes to cache the widths on top of master, it takes 5.844 | 16:52.33 |
| henrys | Robin_Watts: so this development calls into question why we don't load up miles' office instead of marcosw garage. | 16:52.56 |
| chrisl | Grr, why does skype have to flash at me when anyone posts - really annoying.... | 16:53.26 |
| Robin_Watts | henrys: Cos Jogu's machine cost a fortune and it's about 12th of the power of one of the uberservers ? | 16:53.36 |
| ray_laptop | mvrhel_laptop: BTW, a customer noticed that our default CMYK input doesn't map to black. I switched them back to UseFastColor and they were happy, but it does seem problematic that CMYK=0,0,0,1 doesn't map to black | 16:53.40 |
| jogux_mac | robin : is it really a 12th? aw :( | 16:54.06 |
| henrys | Robin_Watts: I'm sorry I haven't looked closely I thought the price point was good | 16:54.06 |
| ray_laptop | mvrhel_laptop: that's when using the default profile for a gray device | 16:54.15 |
| mvrhel_laptop | ray_laptop: what is the situation? is the source color 0 0 0 1 and what is the destination device? | 16:54.50 |
| Robin_Watts | The uberservers have 4 nodes in, each node has 2 6 core CPUs. | 16:55.17 |
| ray_laptop | mvrhel_laptop: pgmgray | 16:55.19 |
| mvrhel_laptop | I am confused if the device is a gray device how it is not neutral output | 16:55.24 |
| Robin_Watts | I think that's right. | 16:55.25 |
| | how many cores does yours have jogu ? | 16:55.35 |
| jogux_mac | robin : I think the pricepoint (about £800+VAT) was okay tbh; I wouldn't expect to pay significantly less for decent quality parts. | 16:55.38 |
| | robin : 4 cores. | 16:55.41 |
| mvrhel_laptop | that would be interesting if it put out something colored | 16:55.45 |
| jogux_mac | I think I could've got more; these CPUs seem to be fairly new / limited availability so not as free a choice as I wanted :( | 16:56.08 |
| ray_laptop | mvrhel_laptop: it is not 100% black. It's not colored, it is like 88% black | 16:56.13 |
| mvrhel_laptop | there is a gamma in the gray profile of 2.2 or so, but 88% does seem excessive | 16:56.43 |
| Robin_Watts | jogux_mac: 800 quid is not an unreasonable price (but then I'd have to put a decent gfx card in it too :) ) | 16:56.48 |
| mvrhel_laptop | I will take a look at that | 16:56.49 |
| jogux_mac | robin : certainly the plan will be for me to send ATS vms back to marcos once they work, so the speed comparison will be interesting. | 16:56.54 |
| | robin : :-) | 16:56.59 |
| mvrhel_laptop | ray_laptop: is there a bug open for this? | 16:57.22 |
| Robin_Watts | But ISTR we got the uberservers for about $1400 each. | 16:57.23 |
| ray_laptop | mvrhel_laptop: I'll check, and open one if not. | 16:57.39 |
| mvrhel_laptop | I fear I am going to have to take a break from my current stuff and spend a week working on gs issues | 16:57.49 |
| ray_laptop | the customer was happy with UseFastColor | 16:57.58 |
| jogux_mac | the uberservers definitely sound good value | 16:57.59 |
| Robin_Watts | They were an incredible deal, but obviously you pay a massive price in noise etc. | 16:58.10 |
| ray_laptop | jogux_mac: they ARE noisy, however | 16:58.29 |
| mvrhel_laptop | ray_laptop: this is the sort of thing that makes me unhappy though | 16:58.31 |
| | until I figure it out and fix it | 16:58.43 |
| | I don't like us having issues like this | 16:58.58 |
| Robin_Watts | jogu: http://www.theserverstore.com/content/dell-poweredge-c6100-servers I think. | 16:59.22 |
| mvrhel_laptop | it is getting warm here. we are supposed to be in the 80s this week. very unusual for late april early may | 16:59.41 |
| chrisl | henrys: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=10fc659b | 16:59.57 |
| mvrhel_laptop | good baseball weather though. my son had a double header on saturday (6 hours of baseball), a 2.5 hour practice sunday, and a 2.5 hour game yesterday. today is a day of rest and then another game tomorrow | 17:00.35 |
| Robin_Watts | We have at least 2 in marcosw's garage, possibly 3. | 17:00.41 |
| jogux_mac | robin : allegedly the 1 CPU in my box is about 40% more powerful than one cpu in the uberbox (but it obivously has a lot more of them ;-) ) | 17:01.54 |
| Robin_Watts | ah, ok. Not sure if Marcosw upspecced the CPUs or not. | 17:02.39 |
| | I thought they were the 6 core ones, but I could be wrong. | 17:03.18 |
| chrisl | Six core is what I remember.... | 17:03.53 |
| henrys | chrisl: looks good to me. I sort of prefer return code to return(code) but either way. | 17:04.55 |
| | chrisl: after you commit I'll see if it gets us back to the 9.06 time. | 17:05.27 |
| | chrisl: for norberts job | 17:05.39 |
| chrisl | henrys: as I mentioned above, for me it's faster than the 9.06 time | 17:05.59 |
| | And I prefer return(code) - but I much prefer consistency, so..... | 17:06.34 |
| henrys | chrisl: oh sorry I missed that timing you reported. my bad | 17:07.08 |
| chrisl | henrys: the difference isn't huge..... | 17:08.30 |
| | henrys, norbertj: committed | 17:08.47 |
| ray_laptop | mvrhel_laptop: I re-opened bug 695107 with description of the CMYK colorspace issue. The original problem was for RGB, but I also added the comment about Black text mapping to a gray shade (it maps to value 0x18 = 0.0674 instead of 0) | 17:58.48 |
| | mvrhel_laptop: I assigned the bug to you. I had mis-remembered -- it was not a customer bug. | 17:59.16 |
| norbertj | chrisl: thanks, just saw it. Going to fix at work too, so I can see the results tomorrow morning. | 18:10.27 |
| mvrhel_laptop | ray_laptop: ok | 18:10.34 |
| chrisl_t530 | norbertj: note that there were changes beyond what I think you saw cluster tested earlier..... | 18:11.00 |
| Robin_Watts | So, the branch added a whole load of stuff to measure rulers etc. | 18:11.43 |
| | and master has stuff to handle multi docs. | 18:12.07 |
| | which means the docs are created later, hence no rulers to measure, hence segvs. | 18:12.19 |
| | jogu, pedro, paulgardiner: Any of you object to the idea of me removing that bloody assert that goes off whenever you pause on a breakpoint for too long? | 18:13.38 |
| norbertj_ | chrisl_t530: I know, so I doublechecked against the commit you made. | 18:56.58 |
| mvrhel_laptop | bbiab | 19:19.57 |
| jogux | robin_watts : hm; I forget it's purpose but I think it may have been important at one time. I think you could certainly wrap it with a if (!IsDebuggerPresent()) thing | 19:41.38 |
| Robin_Watts | I've got it in an #ifndef _WIN32 #endif | 19:42.00 |
| | OK, so many commits on robin/master (sot) | 19:42.19 |
| | OR there will be when git stops churning. | 19:42.38 |
| | The first 7 of which are good to go now. | 19:44.09 |
| | The rest are reapps from the branch. | 19:44.21 |
| mvrhel_laptop | blah. need to add a few more background threads to gsview during startup to avoid the ui lock up when opening large files. | 20:44.48 |
| | off to run an errand will tackle that when I return | 20:45.02 |
| ray_laptop | mvrhel_laptop: can you please have a look at http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=f08d58846370eb6c79254ef9f886f25eb4531f09 | 22:50.56 |
| | mvrhel_laptop: I think this is the root cause of cust 532's issue -- since it only affects the tag, it is VERY low risk for most | 22:51.44 |
| Robin_Watts | ray_laptop: seems reasonable to me. | 22:52.13 |
| ray_laptop | mvrhel_laptop: it looks like it was a simple typo | 22:56.03 |
| | mvrhel_laptop: and it looks like it's been in there since 2011-04-19 | 22:56.04 |
| Robin_Watts | You might want to look at line 4693 too ? | 22:56.15 |
| mvrhel_laptop | ray_laptop: looks correct based upon your 255 vs 0 alpha at this point in the code | 22:59.08 |
| Robin_Watts | I think line 4693 is the same problem repeated. | 22:59.49 |
| | (Search for 'If alpha is 100%...') | 23:00.41 |
| ray_laptop | mvrhel_laptop: the issue with that patch is that it should write the curr_tag based on the SOURCE alpha | 23:01.04 |
| | Robin_Watts: thanks -- I'll look at it | 23:01.17 |
| | mvrhel_laptop: and only write a "blended" (or) tag if the source is not 100% | 23:02.20 |
| Robin_Watts | Your optimisation to avoid remap calls has tripped lots of "code is set but not checked" warnings in gxcmap.c | 23:03.09 |
| ray_laptop | mvrhel_laptop: thinking about it, we also need the other part of the patch so that we don't even touch the tag if the source alpha is 0% | 23:03.11 |
| Robin_Watts | It's possible that they were there already and the checker has just noticed them again though. | 23:03.36 |
| ray_laptop | Robin_Watts: great :-( | 23:03.41 |
| | Robin_Watts: I had performed a regression run, and didn't get those :-( | 23:04.14 |
| Robin_Watts | ray_laptop: It may be machine dependent maybe? | 23:04.35 |
| | ray_laptop: I think you're right about the 0% case being needed. | 23:04.57 |
| ray_laptop | Robin_Watts: I don't know what machine it collects the "new warnings" from | 23:05.10 |
| | Robin_Watts: yeah, I'll add that... | 23:05.33 |
| | Robin_Watts: to both places | 23:05.43 |
| Robin_Watts | me either. It might be "the first one of a set known to have the same gcc version", but maybe one or more of them got upgraded or something? | 23:06.04 |
| ray_laptop | I have to run an errand. bbiaw... | 23:06.52 |
| | mvrhel_laptop: Robin_Watts: thanks for the review | 23:07.13 |
| Robin_Watts | np. always happy to be nosey :) | 23:07.25 |
| ray_laptop | Robin_Watts: do you ever sleep ??? | 23:07.39 |
| Robin_Watts | Any moment :) | 23:07.55 |
| | Jogu: Thinking about what you said about the if (!IsDebuggerPresent()) idea. I don't want to simply do: | 23:08.39 |
| | if (!IsDebuggerPreset()) assert(); cos that will cost time on every thread yield. | 23:09.07 |
| | I could do some #ifdef DEBUG if (condition) { if (!IsDebuggerPresent()) assert(true) } #endif thing though. | 23:10.11 |
| | but I'm inclined to just disable it for windows and be done with it. | 23:10.25 |
| | Forward 1 day (to 2014/04/30)>>> | |
IRC Logs