| <<<Back 1 day (to 2011/11/02) | 2011/11/03 |
Robin_Watts | mvrhel_laptop: On the ubuntu logon screen, you can select different Ubuntu styles. | 00:10.39 |
| One of them is "classic". That's the one you're used to. | 00:10.52 |
| Anyone awake here? | 00:31.21 |
| mvrhel_laptop: ? | 00:31.27 |
| mvrhel_laptop: the clusterpush shows some problems, so I'll look into it more tomorrow. | 00:45.05 |
| henrys: I have an idea about how to make the scan converter do fill adjust too. | 00:45.55 |
arthurf | tor8: I opened up 692656 as an enhancement request for password protected PDF support on the iOS version. | 02:10.48 |
| plays with the new zooming feature in MuPDF for iOS | 03:58.48 |
| tor8: post zoom - the text is blurry - I'm sure you know that already - won't bother writing a defect. | 04:00.47 |
| and a UIActivityIndicator .. very nice instead of the "Loading" text. | 04:03.36 |
mvrhel_laptop | Robin_Watts: sorry I missed you | 04:06.33 |
henrys | mvrhel_laptop:still around? curious if there's any news from ray's meeting | 05:42.59 |
mvrhel_laptop | henrys: I did not hear anything and was wondering how it went too | 06:10.44 |
henrys | I guess we'll find out tomorrow. | 06:20.09 |
Robin_Watts | tor8: Did you try the ARM bitmap scaling code ? | 13:44.16 |
tor8 | Robin_Watts: no, sorry, been distracted by other ios things | 13:44.35 |
Robin_Watts | np. | 13:44.40 |
tor8 | like nesting scroll views (!) to get zooming to work | 13:44.49 |
Robin_Watts | I pushed the 'simple' scaler yesterday. | 13:44.49 |
| Uses 1/4 of the memory, but is no faster :( | 13:45.09 |
| I suspect that iOS has better profiling tools than android. | 13:45.51 |
pipitas | kens: May I ask you a question about font embedding with pdfwrite? | 14:40.23 |
| It's about Ghostscript's way to embed Type1 fonts.... | 14:40.37 |
kens | Yes, but it may take me a few minutes to answer | 14:40.38 |
pipitas | OK then. It also takes a moment to re-test again to make sure I get it right. My memory is like a sieve these days... | 14:41.34 |
| This command creates a PDF which has Courier NOT embedded, naming the font type used as "Type 1": | 14:42.48 |
| : gs -o courier-noembed.pdf -sDEVICE=pdfwrite -c "/Courier findfont 32 scalefont setfont 100 600 moveto (Courier) show showpage" | 14:42.48 |
| The next command creates a PDF which has Courier embedded, but now naming the font type used as "Type 1C": | 14:43.33 |
| : gs -o courier-noembed.pdf -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress -c "/Courier findfont 32 scalefont setfont 100 600 moveto (Courier) show showpage" | 14:43.33 |
| If I add "-dCompatibilityLevel=1.2" to the command, the font will appear as "Type 1", but it will NOT be embedded, no matter what else I do (even adding "-c '.setpdfwrite <<AlwaysEmbed [/Courier] /NeverEmbed []>> setdistillerparams'" doesn't help). | 14:44.19 |
| So, now the Question: is there any way to force GS to use Type 1 (instead of Type 1C) when embedding a Type 1 font? | 14:44.48 |
| (I've tried this with 8.71 as well as 9.x and 9.05git...) | 14:45.18 |
kens | No there is no way to forace type 1 | 14:45.47 |
pipitas | kens: do I remember correctly, that for older versions of GS (older than 8.71), it didn't use the Type1C/CFF for Type1 fonts? | 14:47.37 |
chrisl | Hmm, Type1C is supported in PDF 1.2, isn't it? | 14:50.05 |
pipitas | chrisl: whenever I use "-dCompatibilityLevel=1.2" fonts will not be embedded, whatever else I try.... | 14:51.22 |
chrisl | pipitas: all I meant was *in theory* there's no reason it shouldn't embed a Type1C font stream in a PDF 1.2 file, *but* there may be practical reasons (like buggy Acrobat, or something) | 14:52.45 |
| In fact, that would seem to be the case: "gdevpsf.h:#define WRITE_TYPE2_AR3 4/* work around bugs in Acrobat Reader 3 */" | 14:56.35 |
pipitas | chrisl: yes, I understand (though I don't know the 1.2 spec by heart). But if I can't get GS to embed Courier with CompatibilityLevel 1.2, either it's a (minor) bug, or I'm too stupid to do it right. (However, my main goal is to create a PDF whatever version which has Type1 embedded instead of Type1C. (Distiller also creates Type1C from Type1 when embedding, BTW....) | 14:57.17 |
| chrisl: ah... I didn't see your last comment at first... | 14:57.54 |
kens | Like I said, there is no option to allow that, I'm sure it could be done | 14:57.55 |
| Coureier isa not embedded (I tihnk) for 1.2 because its contra the spec | 14:59.19 |
| Later versions changed that, so you could embed the base 14 | 14:59.38 |
| I don't knw why it wouldn't embed other fonts, it should, but it could be a bug. OTOH wwe don't pay much attention to the old versions | 15:01.28 |
| You could file an enhancemet request to wllow type 1 embedding instead of 1C | 15:02.34 |
| And/or a bug report for embedding fonts in PDF 1.2 output | 15:02.52 |
chrisl | kens: it looks to me like a poor work around for an Acrobat problem. It would make more sense to set "HaveCFF" false for PDF 1.2, instead of quietly not embedding...... | 15:03.45 |
kens | That's possible, I haven't read the code ;-) | 15:04.05 |
| HaveCFF is really for ps2write output I think, but it coulsd be repurposed for PDF. | 15:04.23 |
pipitas | kens: in fact it *might* embed other fonts with PDF1.2 -- I only tried with Courier | 15:04.29 |
kens | Ah, OK, I'm fairly sure that in versions that old you were not supposed to embed the base 14 fonts | 15:04.48 |
| Which is probably why it doesn't do it. THe logic is quite hairy, since Adobe changed the spec.... | 15:05.18 |
| As chrisl notes, try -dHaveCFF=false | 15:05.40 |
| With a newer version of compatibility. It should embed as type 1. | 15:05.57 |
pipitas | I always thought it was a *recommendation* to not embed the base14 in PDF1.2 (and hence the default behavior for most PDF creators), but not that it was explicitely *forbidden* in the spec... | 15:06.28 |
kens | Most creators chose to interpret 'recommended' as 'do this'. | 15:06.54 |
chrisl | I don't know if HaveCFF can be set explicitly, rather than implicitly by the PDF version...... | 15:07.04 |
kens | I think it can, we use HaveTransparency similarly | 15:07.22 |
pipitas | Adding a "-dHaveCFF=false" to the commandline still embeds as Type1C/CFF | 15:08.19 |
kens | OK, well it may get overridden. | 15:08.32 |
| Other than that, its a code change | 15:08.47 |
mvrhel_laptop | Robin_Watts: you there? | 15:24.16 |
Robin_Watts | I am. | 15:28.19 |
| Scott says "We had a great meeting with Company C yesterday. More at the staff meeting." | 15:28.48 |
mvrhel_laptop | great | 15:30.00 |
| so if you are organizing something for the everglades myself +3 would be interested. | 15:30.47 |
Robin_Watts | Was just talking to Scott about that. | 15:31.00 |
| So far, it's Me,Helen,Ken,Chris,Tor(+1 maybe?),Scott,Ellen,You+3 | 15:31.45 |
| Either we can all book onto one of the organised tours (minibus pickup from hotels, out to everglades, boat trip, back on bus, back home) | 15:32.21 |
| or we can sort out a private tour. Private tours are better as you get longer on the boats (apparently standard tours are 30 mins or so, and you want at least an hour) | 15:33.10 |
| We'll see if we can sort out a minibus to pick us all up for a private tour. | 15:33.32 |
mvrhel_laptop | That sounds like a plan. | 15:33.50 |
kens | Sounds good | 15:33.56 |
Robin_Watts | It may be possible to do both Everglades and Key Largo in one hit (Key Largo is 63 miles away). | 15:34.14 |
| Key West is much further, I think. | 15:34.39 |
| Key Largo has things like glass bottom boat tours. | 15:34.52 |
| Helen is going to look into it - she's good at this kind of stuff. | 15:35.11 |
kens | Both would be nice.... | 15:37.04 |
mvrhel_laptop | ok. thanks for organizing. when you give a head count to any private boat make sure to that they know 2 in the count are small children as they may not count in the total cost | 15:37.11 |
| or may be reduced | 15:37.23 |
Robin_Watts | mvrhel_laptop: Will do. | 15:37.30 |
| I know henry can't come (as he's staying on after the meeting rather than coming before). | 15:38.42 |
| Dunno about ray or alex or miles. | 15:38.53 |
henrys | I wish I waited to book... I wonder how hard it would be to change. | 15:46.21 |
Robin_Watts | Can someone try the following please? | 15:50.46 |
| xps/debugobj/gxps.exe -sDEVICE=png16m -dFirstPage=2 -dLastPage=2 -o out.png ../ghostpcl/tests_private/xps/xpsfts-a4/fts_38xx.xps | 15:50.59 |
henrys | snorkeling on largo is good | 15:51.11 |
Robin_Watts | The -dFirstPage/LastPage stuff seems to break it for me. | 15:53.45 |
kens | Tjhat was broken before, I thought it got fixed. | 15:54.04 |
Robin_Watts | Also, the rendition of one of the radial shadings is broken on page 4. My current patch fixes it, but seems to break another file :( | 15:54.54 |
kens | I get some internal errors (debug build) | 15:56.49 |
Robin_Watts | ending in a -102 error code ? | 15:57.04 |
kens | Yes, 'cannot flush page' cannot parse fixed page etc | 15:57.23 |
| error code -102 | 15:57.31 |
Robin_Watts | yeah, same as me. Not something I've broken then :) | 15:57.35 |
kens | Removing FirstPage and LastPage fixes it | 15:58.29 |
henrys | congrats kens on the text extraction! | 16:02.51 |
kens | Thanks henrys :-) | 16:02.59 |
| Going to be a long bug tail on it, I have no doubt | 16:03.10 |
henrys | ray_laptop:we wanted to hear about the meeting, how'd it go? | 16:06.07 |
| scott said it was good but sometime scott doesn't follow all the details. Have we go a lot of work to do? | 16:06.54 |
| s/go/got | 16:07.01 |
ray_laptop | the meeting went surprisingly well. | 16:08.11 |
| they were VERY intent on getting an aggressive price quote from Miles, but also they are thinking that for low end inkjet machines with their 'cost sensitive controller' that mupdf might be a good fit | 16:09.23 |
henrys | interesting ... | 16:10.17 |
ray_laptop | they wanted ARM9 rom sizes and RAM footprints for the Jetta files (and performance when we can get it) for gs and mupdf | 16:10.38 |
henrys | what's a Jetta file? | 16:11.37 |
kens | Another test suite ? | 16:11.54 |
ray_laptop | so doing a 'stripped to the bone' gs build for the ARM would be needed. I am looking into getting the 'source' documents for the Jetta (JIS) files | 16:12.14 |
| cust 532 uses these a lot as well for performance benchmarks | 16:12.41 |
henrys | they just want ps and pdf? | 16:12.57 |
ray_laptop | They are interested in PCL as well, and maybe XPS (no strong interest, however), but it all comes down to price. Buy PDF for low end inkjets and lasers is their 'hot button' and RAM footprint for various files may add to their decision. | 16:14.57 |
henrys | mvrhel_laptop had said something about our performance lacking relatively, I was concerned that was going to be an issue. | 16:15.14 |
ray_laptop | the only thing they shared about performance was "we are about the same" | 16:15.25 |
henrys | that's really good news ... | 16:15.42 |
ray_laptop | but they admitted that they hadn't ever asked us for help in 'optimizing' | 16:15.49 |
| I hope that Miles gets aggressive with the pricing (they kept mentioning a $79 inkjet that their controller board is in) | 16:16.58 |
| so the controller cost is probably down around $5 or so | 16:17.24 |
| Miles and Scott were pretty 'stoked' by the possibility that this may turn around | 16:18.25 |
henrys | at the same time the negotiations shouldn't just come down to controller price. I am sure the printer company is selling these things at a lose for consumable revenue. | 16:23.30 |
ray_laptop | henrys: probably not at a loss, but at a slim profit margin. The ink market has gottem less profitable with 'refill kits' and third party ink suppliers (non OEM inks) | 16:24.58 |
Robin_Watts | Surely controller price is a better indicator than 'end product' sale price? | 16:25.02 |
ray_laptop | well, we want a % of the printer, not just the controller -- we've been burned by that before | 16:25.59 |
mvrhel_laptop | ray_laptop: this all sounds good | 16:26.43 |
ray_laptop | Robin_Watts: they didn't share their controller price -- that's totally a WAG by me. | 16:26.57 |
| but if they sell 3 million of these low end inkjets ... | 16:27.33 |
Robin_Watts | ray_laptop: My point is that they might be selling the controller for a higher price than you'd imagine based on the end product price if it's subsidised by future ink revenues. | 16:27.55 |
| WAG? | 16:28.04 |
marcosw_ | henrys and ray_laptop: I'm busy preparing for my 10am meeting, can we postpone the support meeting to this afternoon? Say 1:00pm? | 16:28.10 |
ray_laptop | wild assed guess | 16:28.12 |
Robin_Watts | Ah :) | 16:28.21 |
henrys | marcosw_:okay | 16:28.30 |
ray_laptop | as opposed to SWAG (S = scientific) | 16:28.32 |
marcosw_ | thx | 16:28.34 |
henrys | marcosw_:I did want to get an answer to that customer (I sent mail to you and the customer) | 16:29.04 |
marcosw_ | yes, it's on the top of my to do list. | 16:30.11 |
henrys | ray_laptop:were any clues dropped about our competitor's prices? | 16:30.21 |
ray_laptop | BTW, I pushed for a rough estimate on how much RAM the RIP might have available. I was pleasantly surprised when they said 24M. Their chip does all of the color conversion from sRGB and halftoning -- we just deliver 24-bit data | 16:30.33 |
henrys | woohoo! | 16:30.52 |
ray_laptop | henrys: no, and they weren't mentioning any competors by name, | 16:30.59 |
henrys | although we do have a few pcl files that simply won't run in 24M contone - I am sure many pdf's with tranparency are the same. | 16:32.01 |
kens | With MuPDF ? | 16:32.21 |
| Don't know if MuPDF requires less memory.... | 16:32.32 |
henrys | a question for tor8 | 16:33.36 |
| anybody have anything for shelly to work on? If so just make it bountiable he's checking the list. | 16:35.10 |
tor8 | yeah, 24Mb will be tight for transparency with mupdf | 16:36.07 |
ray_laptop | tor8: even when delivering just bands ? | 16:36.23 |
chrisl | henrys: Shelly's asking about jbig2dec - apparently there's 17 open issues on it right now..... | 16:36.41 |
tor8 | it'll be tight on big image files too, unless we can get the "be smart about not loading the entire image" project going | 16:36.45 |
ray_laptop | tor8: smarter would be nice | 16:36.59 |
tor8 | ray_laptop: well, if the transparency stack becomes deep... | 16:37.04 |
kens | Always a problem with PDF transparency | 16:37.27 |
ray_laptop | tor8: then you just restart that part with a smaller band. | 16:37.28 |
| but you can still deliver the final RGB band whatever size they need | 16:37.53 |
tor8 | ray_laptop: yeah. so the image loading stuff is the only real problem then... | 16:38.02 |
| a problem which won't go away for JPEG2000 no matter how you slice it | 16:38.29 |
ray_laptop | the performance on killer files might get sort of piggy, but even if we're doing a single raster line at a time | 16:38.46 |
kens | OK back to bugs for me, I htink I need to look at the transparency flattening first. I suspec that something in the colour handling has broken it, so I may need to talk to mvrhel2 | 16:38.51 |
ray_laptop | tor8: luratech manages to load JPX files with a LOT less memory than open jpeg or jasper | 16:39.27 |
henrys | Robin_Watts:which arm processor do you have I now have a printer customer asking about the cortex A9? | 16:39.31 |
Robin_Watts | The beagleboard has an A8 or A9 in it. Let me check. | 16:39.54 |
| A8. | 16:40.08 |
kens | Can it take an A9 ? | 16:40.29 |
| Not sure if thay have different pin-out | 16:40.50 |
Robin_Watts | kens: I am *not* unsoldering a surface mount processor :) | 16:40.50 |
kens | Coward :-) | 16:40.59 |
Robin_Watts | The pandaboard has an A9. | 16:41.08 |
ray_laptop | Robin_Watts and Tor: can one or both describe (email fine) what ARM specific optimizations we have ? | 16:41.12 |
kens | Sounds liek a bet then, how much ? | 16:41.17 |
Robin_Watts | (so we could get an A9) | 16:41.18 |
henrys | We really should have ready minimum processor speeds for say 25 50 and 100 ppm in some reasonable amount of memory for simple jobs. | 16:41.21 |
Robin_Watts | ray_laptop: For gs? No ARM specific optimisations. | 16:41.30 |
| For mupdf? the core processing loops of the bitmap scaling routines are ARM optimised. | 16:41.52 |
ray_laptop | Robin_Watts: do any of the ARM chips have SSE that we can use ? | 16:42.01 |
Robin_Watts | ray_laptop: Xscale had SSE. No one uses Xscale these days. | 16:42.18 |
| The later ARMs have SIMD stuff inbuilt. | 16:42.36 |
ray_laptop | Robin_Watts: well, bitmap scaling probably won't be used that much will it ? | 16:42.38 |
Robin_Watts | so we could potentially use it. | 16:42.45 |
ray_laptop | Robin_Watts: the NEON extensions ? | 16:42.49 |
Robin_Watts | ray_laptop: NEON offers some SIMD, but there are some SIMD things even without NEON in arch 7. | 16:43.17 |
ray_laptop | Robin_Watts: I see. | 16:43.27 |
Robin_Watts | bitmap scaling is used LOTS. | 16:43.50 |
ray_laptop | BTW, they want (at the final stage) bands that are line interleaved RGB | 16:43.55 |
| Robin_Watts: oh, so it is used for image scaling (not just zooming) | 16:44.22 |
Robin_Watts | Planar Line Interleaved Buffer. That's what the plib devices are for. | 16:44.49 |
ray_laptop | Robin_Watts: right. Thanks | 16:45.05 |
henrys | Robin_Watts:clockspeed for the A8 and do you have any ppm numbers? | 16:45.06 |
Robin_Watts | ray_laptop: Yes, we scale images down before plotting. | 16:45.08 |
| Beagleboard A8 = 600MHz or thereabouts. | 16:45.24 |
ray_laptop | Robin_Watts: plotting -- that's a term I haven't heard for years | 16:45.32 |
Robin_Watts | henrys: Not off the top of my head, but I can dig some up. | 16:45.52 |
ray_laptop | what speed it the pandaboard ? | 16:46.04 |
henrys | Robin_Watts;I'm sorry to be a bother but I do need them. | 16:46.21 |
| 300 dpi 32bp | 16:46.50 |
Robin_Watts | pandaboard = 1GHz ARM Cortex-A9. | 16:47.19 |
| henrys: Want to nominate some specific files for timings ? | 16:47.36 |
henrys | Robin_Watts:would you like to speak with the customer directly or have me be the in-between? | 16:47.37 |
| PLRM | 16:47.49 |
Robin_Watts | I'm happy to speak directly. | 16:47.52 |
| OK. | 16:47.54 |
| I'll do those timings in a bit (midway through cutting down a file) | 16:48.20 |
ray_laptop | henrys: Do we want to use the Jedda files that I have from cust 532 ? | 16:48.51 |
henrys | we should have those files in a public area perhaps in the overnight test suite right? | 16:50.14 |
Robin_Watts | tests_private/jetta ? | 16:50.39 |
ray_laptop | henrys: the trouble is that the source "Jetta" files are then 'printed' through a driver to produce the PDF or PS or PCL, so I don't know the 'provenance' of these and if they will match what Company C has. | 16:51.29 |
henrys | are these application files or some intermediate form like xps? | 16:52.40 |
ray_laptop | Robin_Watts: OK, I'll go ahead an upload some with a 'readme.txt' to tell what I know about them. Some of the PDF's I have came out the back of acrobat with transparency flattened, for example. | 16:52.45 |
| henrys: I think the original are similar to the ATS files | 16:53.02 |
| but I've never seen the original | 16:53.14 |
| I'll ask Len | 16:53.27 |
| henrys: I just found out by looking at the 'ps' files cust 532 gave me. They have a PJL header with comments in them: | 16:56.57 |
| @PJL COMMENT="APP:C:\Program Files\Microsoft Office\Office14\EXCEL.EXE; | 16:56.58 |
| @PJL SET JOBNAME="J10.xls 120610 182715" | 16:57.00 |
| so they _are_ application files. | 16:57.12 |
| I see Excel, PowerPoint, WinWord, AcroRd32 (so probably originally a PDF file), and one that just says "full page photo" | 16:59.55 |
henrys | well to get the highest level representation we'd want to export them from the app as pdf I think that makes the more sense than squashing them with a print driver. | 17:00.24 |
ray_laptop | there are 12 files some of which output multiple pages | 17:00.33 |
henrys | Robin_Watts:you should have mail, I assume you understand -san ... | 17:01.32 |
ray_laptop | henrys: I'll upload (cleaned up) versions of the PS, PDF 1.3 and PDF 1.4 (if it differs from the PDF 1.3) | 17:01.47 |
henrys | okay and we'll have marcos put them in the nightly. | 17:02.35 |
kens | Time for me to go, night all | 17:02.40 |
ray_laptop | does anyone ever look at the nightly ? | 17:02.57 |
Robin_Watts | henrys: It's an honorific added to the end of a japanese name to mean "Mr XXXX". A sign of respect. | 17:03.05 |
kens | I doI do | 17:03.06 |
Robin_Watts | kens: Are the nightly results available on line? | 17:03.34 |
| I should add links to them from the dashboard. | 17:03.40 |
kens | Err, not sure, I just read hte nightly email | 17:03.54 |
mvrhel_laptop | henrys: so I am trying to get my new computer set up and something strange is going on. I am getting a build error with pcl | 17:10.13 |
| it is complaining about a redefinition of struct timeval | 17:10.39 |
| in time_.h | 17:10.47 |
henrys | Robin_Watts:just checkin... | 17:11.32 |
mvrhel_laptop | I have probably made some silly mistake someplace | 17:11.36 |
Robin_Watts | henrys: No worries. | 17:11.48 |
| mvrhel_laptop: This is a vanilla checkout with VS2008 on windows 7 64bit ? | 17:12.08 |
mvrhel_laptop | this is vanilla linux | 17:12.20 |
Robin_Watts | Oh, right. | 17:12.28 |
henrys | hmm really | 17:12.29 |
mvrhel_laptop | VS is all ok | 17:12.32 |
| ghostscript built fine on linux | 17:12.42 |
henrys | which file is including time when the error occurs? | 17:13.02 |
mvrhel_laptop | it looks like gp_unix.c | 17:13.19 |
chrisl | For recent Linux versions, I had to change the configure check for something like this, let me try to find the commit...... | 17:14.55 |
Robin_Watts | My shading changes have produced one regression. I've cut that file down to a single shading, and going to pbmraw, it produces a solid black circle rather than a properly shaded one, whereas png works fine. | 17:15.10 |
| The file contains a reference to an ExtGState of Xi10, which is never used. | 17:15.48 |
| But if I remove that definition from the file, it works. | 17:15.57 |
| I am minded to commit my shading changes, and open a pdf interpreter bug with the cutdown file attached. Anyone disagree ? | 17:19.11 |
chrisl | mvrhel_laptop: what version of Linux are you using? | 17:19.28 |
henrys | mvrhel_laptop:you are running autogen.sh in the ghostpdl directory (above gs) - I am sure that won't fix your current issue but I wanted to make sure you are using it for other stuff. | 17:19.37 |
mvrhel_laptop | chrisl: hold on | 17:20.00 |
| it is 11.10 | 17:21.55 |
| henrys: I did run autogen.sh in the ghostpdl directory followed by configure | 17:22.23 |
| like it says in the read me | 17:22.27 |
henrys | great | 17:22.35 |
| chrisl:fwiw I don't think any of the languages (pcl,xps, pxl) need time. Another omnibus header file sigh... | 17:23.42 |
mvrhel_laptop | Robin_Watts: that sounds reasonable | 17:24.28 |
chrisl | Okay, the problem is, I think, they've moved or futzed with time.h so the (stoopid) hard coded path test in unix-aux.mak doesn't work :-( | 17:24.46 |
| henrys: it's need in the graphics lib - I don't know what would be involved in pulling that dependency out..... | 17:25.15 |
henrys | chrisl:probably not worth tracking down. | 17:26.01 |
chrisl | I'll have a look at a reasonable way to fix this - since my squash match was just cancelled :-( | 17:26.56 |
mvrhel_laptop | ok. thanks chrisl | 17:30.02 |
| brb | 17:33.14 |
chrisl | I think I need to update my VM to the Oneiric release rather than the beta I've got right now.... | 17:47.52 |
Robin_Watts | mvrhel_laptop: I just pushed the fix for bug 692513 (or the part of it you passed to me). | 17:55.23 |
mvrhel_laptop | ok great | 17:58.36 |
| I think the only other issue for this file is related to the stroking issue | 17:58.58 |
| with patterns | 17:59.02 |
| I need to make that pattern for you still | 17:59.13 |
Robin_Watts | alexcher: Let me know if bug 692657 is unclear. | 18:00.34 |
chrisl | mvrhel_laptop: if you pull an update, it *should* build now. | 18:06.53 |
mvrhel_laptop | ok let me try | 18:07.06 |
| ok seems to be working | 18:08.32 |
| thanks chrisl | 18:08.45 |
chrisl | Cool! :-) | 18:09.03 |
| You got lucky - I was supposed to be losing at squash right now...... | 18:09.39 |
mvrhel_laptop | off to lunch. | 18:15.25 |
alexcher | Robin_Watts: OK, I'm looking. | 18:42.44 |
Robin_Watts | alexcher: If it's really a shading bug then just throw it back at me. | 18:43.35 |
tor8 | Robin_Watts: image rendering seems to be a bit off at various zoom factors | 19:10.56 |
| *playing with the zoom feature of the iOS app* | 19:11.09 |
Robin_Watts | tor8: With the ARM stuff, or without ? | 19:11.12 |
tor8 | without. images seem to shift around a pixel or so (sourcee pixels) | 19:11.32 |
Robin_Watts | When zooming up or down ? | 19:11.52 |
tor8 | when I'm doing the zoom I'm drawing an upscaled version of the full page image, until the zooming stops when I rerender a screen ful | 19:12.02 |
| zooming in, the images shift around but the rendered text stays put | 19:12.22 |
| might be something to do with where we align the center-of-pixels | 19:12.46 |
Robin_Watts | Disable the calls to fz_scale_pixmap and see if the problem goes away ? | 19:12.56 |
tor8 | ohhh, or it could be the darned grid fitting we do! | 19:13.23 |
| let me try disabling that | 19:13.26 |
Robin_Watts | We grid fit to the nearest destination pixel. | 19:13.43 |
tor8 | nope, no difference | 19:15.01 |
| trying to disable scaling now | 19:15.25 |
| scaling makes no difference either | 19:25.02 |
| I think our plotting is off :( | 19:27.38 |
Robin_Watts | Well, that's a relief :) | 19:27.41 |
| ray_laptop: Did you get the android version working ? | 19:28.07 |
henrys | whenever you're ready marcosw_ | 19:57.42 |
marcosw_ | we can start now. | 19:57.55 |
| how many weeks back would you like to go? | 19:58.03 |
henrys | I guess since the last meeting. | 19:58.36 |
marcosw_ | that would be 3 weeks... | 19:58.50 |
henrys | 10/20/2011? | 19:59.29 |
| that can't be right | 20:00.04 |
| or 10/13? | 20:00.47 |
marcosw_ | I left town on the 18th. I think we met the week before. | 20:00.58 |
henrys | okay so let's start with the 20th | 20:01.18 |
ray_laptop | Robin_Watts: sorry -- was on the phone. the app wouldn't load on my unit. | 20:01.24 |
marcosw_ | that's http://bugs.ghostscript.com/show_bug.cgi?id=692589 | 20:01.31 |
Robin_Watts | ray_laptop: Odd. It's a 2.2 unit, right? | 20:01.40 |
henrys | marcosw_:next is 590 | 20:02.14 |
ray_laptop | Robin_Watts: yes, but I just showed them summatra and that was enough | 20:02.24 |
henrys | 589 is okay as is. | 20:02.38 |
| it isn't clear to me if 590 should be closed or what. Maybe a reminder? | 20:03.25 |
marcosw_ | I was wondering why 590 isn't closed. | 20:03.49 |
henrys | are you driving? | 20:04.21 |
ray_laptop | alexcher: can you close 590 if you think it's all solved ? | 20:04.24 |
henrys | kens should close it. | 20:04.42 |
| just needs a reminder. | 20:04.51 |
marcosw_ | I have no idea if I'm driving or not. | 20:04.55 |
henrys | marcosw_:please drive | 20:05.15 |
ray_laptop | yes, please | 20:05.21 |
marcosw_ | gladly. | 20:05.22 |
henrys | you've had the most practice. | 20:05.45 |
marcosw_ | I've added a comment to Ken to 590. | 20:06.08 |
| 591 looks reasonable as is. Should it be bountiable :-) | 20:06.42 |
henrys | 591 needs a ping to alex | 20:06.45 |
| if somebody gives us a patch we should respond I think. | 20:07.19 |
marcosw_ | done. | 20:07.29 |
henrys | and bountiable | 20:07.41 |
ray_laptop | except for all of tim w's trivial bugs, IMHO | 20:08.42 |
marcosw_ | 592 is okay; presuming we continue to assign all muPDF bugs to Tor by default. | 20:08.52 |
henrys | btw any tim wagh bugs go to alexcher. | 20:08.55 |
| or at least he's agreed to triage them. | 20:09.20 |
ray_laptop | ok | 20:09.32 |
| as long as it's not me ;-) | 20:09.44 |
henrys | so 598 to alexcher | 20:09.49 |
| and 599 | 20:10.11 |
ray_laptop | since I haven't gotten a response, can I close 600 ? | 20:10.30 |
henrys | yes the coverity things are questionable. | 20:10.37 |
marcosw_ | wonders if we can write a rule to assign all bugs from tim to alex automatically. | 20:10.45 |
ray_laptop | 599 doesn't show on my list | 20:10.45 |
henrys | yup for 600 but marcosw_ should follow up, right? | 20:11.32 |
marcosw_ | one sec , I'm reassigning all of tim's bugs | 20:11.52 |
henrys | sorry 599 is resolved fixed | 20:11.55 |
ray_laptop | OK. 600 closed. Generally he responds to the bug comment posting | 20:12.14 |
henrys | kens ears must have been ringing | 20:12.25 |
kens | Did I miss something ? | 20:12.55 |
| Haven't readf logs yet | 20:13.05 |
ray_laptop | kens: just wondering if you can close 692590 | 20:13.32 |
kens | I'll go look | 20:14.01 |
henrys | ray_laptop gets 602 | 20:14.07 |
kens | launches Firefox | 20:14.15 |
ray_laptop | can marcos reproduce it ? | 20:14.28 |
marcosw_ | 602 is assigned to ray, I can try to reproduce it... | 20:14.48 |
henrys | yes I was jumping the gun sorry | 20:14.56 |
ray_laptop | marcosw_: nm. It looks like I only need to explain it | 20:15.08 |
marcosw_ | okay, I'lve reassigned it to you. | 20:15.30 |
Robin_Watts | henrys: pspcl6 on the beagleboard: 300dpi plib = 4 minutes 46 seconds for PLRM. | 20:15.30 |
kens | ray_laptop : No I don't think I should close that bug, the pdfwrite output is incorrect is it not ? Alex's patch just fixes the PDF itnerpreter so that it deals with the problem I think | 20:15.42 |
Robin_Watts | I'll write an email after dinner. | 20:15.44 |
kens | Unless its legal to have a self-referencing SMask, which doesn't sound likely | 20:16.14 |
ray_laptop | Robin_Watts: what mode (how much RAM ?) and disk or memory clist if banded ? | 20:16.26 |
henrys | Robin_Watts:he'll want a PPM number. | 20:16.30 |
marcosw_ | 604 is an interesting bug. ray_laptop? | 20:17.15 |
henrys | 604 is probably won't fix soon. We know there are problems with error messages. | 20:17.16 |
| laterland? | 20:18.04 |
marcosw_ | I changed it to enhancement | 20:18.29 |
ray_laptop | if it was up to me, I'd close 604 | 20:18.32 |
marcosw_ | ray_laptop: it's up to you now. I assigned it to you :-) | 20:19.03 |
henrys | wow I never even noticed 607 good thing we have these meetings ;-) | 20:19.23 |
ray_laptop | marcosw_: the command line UI is NOT designed for people that can't read carefully. | 20:19.24 |
henrys | 607 is fixed | 20:19.46 |
marcosw_ | 606 is okay as is. | 20:19.52 |
| henrys: you'll close 607? | 20:20.19 |
henrys | okay | 20:20.25 |
marcosw_ | is 608 yours or Ken's? | 20:20.54 |
henrys | 608 is fine with me. | 20:21.28 |
ray_laptop | ken'll will have to review the patch | 20:21.29 |
kens | I think #692655 (assigned to Alex) should be mine. Its Coverity, but its my area I think | 20:21.37 |
| #692608 ? There's no patch is there ? | 20:22.00 |
marcosw_ | 609 is okay. | 20:22.23 |
henrys | I told alexcher that if he was confident to just commit otherwise assign to owners if you don't like that plan holler! | 20:22.28 |
ray_laptop | kens: no, if someone fixes it under the bounty program | 20:22.31 |
kens | Oh, right ;-) | 20:22.38 |
marcosw_ | 610 is okay. | 20:23.00 |
henrys | 611 looks like bad news... | 20:23.38 |
| oh this is gc stuff. | 20:23.59 |
kens | I haven't looked at it yet, I'm unconvinced | 20:24.01 |
Robin_Watts | henrys: 190ppm ? | 20:24.08 |
alexcher | henrys: there are differences and I'm trying to figure out whether they are real or just indeterminisms. | 20:24.10 |
henrys | does ray_laptop's vmreclaim change fix 611 | 20:24.41 |
| ? | 20:24.42 |
marcosw_ | I can isolate 611 to a specific revision. | 20:24.53 |
kens | Don't know, I haven't tested it | 20:24.56 |
| I would doubt it, as that would be present in old versions too | 20:25.07 |
| (vmreclaim usage that is) | 20:25.16 |
ray_laptop | I suspect it might because there are 19331 gs_gc_reclaim calls | 20:25.28 |
kens | Crumbs.... | 20:25.36 |
henrys | alexcher:I think if you are at that point you should probably reassign to owner. | 20:25.51 |
marcosw_ | brb | 20:26.59 |
henrys | bader already narrowed it down and this is a general problem I've noticed. fixing the reclaim is a mask. The colorspace allocations can get horrendous on some files. This is a pcl problem also. | 20:28.10 |
| I think we need to have a special cache for the device color spaces, not a separater allocation each time. | 20:28.49 |
| so I'd like to assign it to michael and talk with him about it objections? | 20:29.46 |
kens | Sounds good to me ;-) | 20:29.55 |
alexcher | henrys: every cluster run ends with some differences and errors. Even cluster run on an unchanged code has them. We need to open the season on indeterminisms. They slow everything down. | 20:30.35 |
marcosw_ | I'm back, sry. | 20:30.36 |
kens | Be back in a bit. | 20:30.41 |
marcosw_ | is 611 okay as is? | 20:30.54 |
ray_laptop | have to go -- call from cust 532 | 20:31.17 |
henrys | okay | 20:31.43 |
marcosw_ | henrys: do you wan to carry on without ray_laptop or wait until he comes back? | 20:31.49 |
henrys | let's continue | 20:32.04 |
| alexcher we can try p1 bugs again. | 20:32.17 |
marcosw_ | 612 is good as is. | 20:32.41 |
| as is 613 | 20:33.00 |
Robin_Watts | henrys: Sorry - was this the customer that wanted plib? Or should the timings be for ppmraw ? | 20:33.07 |
henrys | Robin_Watts:he didn't say just 32 bit output. | 20:33.43 |
Robin_Watts | by which he means 24, right? :) | 20:34.09 |
marcosw_ | 615 is okay. | 20:34.10 |
| so is 616 | 20:34.22 |
henrys | I read that as CMYK | 20:35.10 |
marcosw_ | 618 is being actively worked on. | 20:35.14 |
| 619 is waiting for openjpeg | 20:35.45 |
henrys | 620 is fine with ken | 20:36.44 |
marcosw_ | 620 is correctly assigned. | 20:36.46 |
| 623 is just a reminder | 20:37.07 |
| 624 is ken's | 20:37.30 |
| I've assigned 625 to me to see if the patch that is attached fixes the problem. | 20:38.29 |
henrys | great | 20:38.41 |
marcosw_ | I should duplicate 626, so I've assigned it to me as well. | 20:39.05 |
kens | I'll probably not do anything with 692620, since we want pdfwrite to do linearised files. But its fine to leave it with me | 20:39.06 |
henrys | kens:you've got a lot o' new ones. | 20:39.23 |
kens | Yes, been busy with the txtwrite stuff, they buildup.... | 20:39.36 |
marcosw_ | brb | 20:39.51 |
kens | Going to start back on them tomorrow, beginning with the flattened transparency issues. | 20:39.57 |
| There are a number of possibly related problems with images | 20:40.08 |
henrys | I'm up to 642 | 20:43.40 |
| 650 should go to michael | 20:45.23 |
| or Robin_Watts | 20:45.51 |
| or maybe not I thought that was the new ht code. | 20:46.55 |
| marcosw_:back - is 658 a customer? | 20:50.20 |
kens | I don't think so. | 20:50.47 |
| BAE systems ? | 20:50.51 |
| Yes, BAE systems. | 20:51.13 |
| Not a customer at the moment, but they raise a lot of bugs | 20:51.25 |
henrys | okay I'll refer to Scott | 20:52.50 |
marcosw_ | i"m back. | 20:52.54 |
kens | henrys it looks like a real bug, so I do need to address it sometime, assuming tis not already fixed. We have a number of customers doign PDF/A | 20:53.36 |
henrys | right | 20:53.54 |
marcosw_ | 658 was entered badly, I'm fixing the fields and assigning to Ken. | 20:54.21 |
kens | :-( | 20:54.34 |
| My bug list is growing.... | 20:54.51 |
henrys | midair collision | 20:54.52 |
marcosw_ | are we done? Any support bugs to discuss? | 20:55.26 |
henrys | searching suppor | 20:56.30 |
marcosw_ | http://bugs.ghostscript.com/show_bug.cgi?id=692470 | 20:56.59 |
henrys | 638 to tor | 20:57.10 |
marcosw_ | you are starting at the bottom? | 20:58.01 |
henrys | I just did a search and that one was on top. | 20:58.45 |
marcosw_ | 548 to me to continue investigating. | 20:58.48 |
henrys | 531 look like it can be closed unless I'm missing something | 21:00.13 |
marcosw_ | agree. | 21:01.07 |
henrys | 536 for chrisl | 21:01.26 |
| or close it | 21:01.41 |
marcosw_ | or close, since it was presumably fixed by gnu make | 21:01.44 |
chrisl | I'd be inclined to close it, given the lack of response | 21:02.02 |
arthurf | henrys: actually 638 is about the bug tracker - need fields to enter ios defects - I selected Bug tracker in the defect | 21:02.27 |
henrys | 692497 to michael | 21:02.50 |
marcosw_ | arthurf: oops, sorry about that, didn't read the description. | 21:03.05 |
| I've assigned 638 to me. | 21:03.23 |
arthurf | marcosw_: thanks | 21:03.37 |
henrys | oh okay sorry arthurf | 21:03.40 |
| we don't actually read these crazy reports ;-) | 21:03.57 |
marcosw_ | that leaves http://bugs.ghostscript.com/show_bug.cgi?id=692540, which I've read but am not sure how to deal with. | 21:04.30 |
henrys | what about 470? | 21:04.52 |
arthurf | henrys: :) No prob - just wanted to say something while the bug list review is in progress. Back to lurking. | 21:05.05 |
chrisl | marcosw_: close 540 - it's not our problem any more | 21:05.34 |
henrys | yes | 21:06.07 |
marcosw_ | which leaves 470 | 21:06.28 |
henrys | right locale hell | 21:06.39 |
marcosw_ | who's the go to guy for locale? | 21:06.51 |
henrys | some guy named bountiable | 21:07.26 |
| chrisl do you want to dispense with that one you did comment? | 21:07.42 |
| oh no you didn't comment | 21:07.59 |
chrisl | Assign it to me if you want. | 21:08.21 |
marcosw_ | chrisl: don't need to tell me twice, done. | 21:08.55 |
henrys | thank god | 21:08.57 |
chrisl | :-) I'll look at it tomorrow, and decide whether to bounty it or not | 21:09.25 |
henrys | shelly is looking for work ! | 21:09.44 |
chrisl | True. As I said earlier, I was hoping to punt some of the jbig2dec bugs his way | 21:10.16 |
kens | Sounds like a good idea if there are several | 21:10.32 |
| Saves re-learning the code each time | 21:10.40 |
chrisl | He said there were 17 open jbig2dec issues, which I thought was rather a lot...... | 21:11.04 |
henrys | that's a good idea. | 21:11.39 |
kens | COuld be duplicates | 21:11.42 |
chrisl | Hopefully, yes. Do we a JBIG2 spec in the company? | 21:12.20 |
| s/a/have a | 21:12.29 |
| Actually, I'd like to grab Bug 692646 if that's okay with alexcher? (I don't like using memcmp() to compare arrays of numbers) | 21:14.30 |
kens | I have one I think ;-) | 21:15.31 |
| JBIG2 spec that is | 21:15.54 |
chrisl | I'll point Shelly at you, then..... | 21:16.30 |
| henrys: shall I give Shelly the "go" to look at jbig2dec bugs, then? | 21:16.57 |
henrys | yes I also asked him to look at embedded fonts for pcl->pdf he seems to like pcl. | 21:18.29 |
chrisl | Does anybody like PCL? ;-) | 21:18.50 |
henrys | maybe like is not the operative word. | 21:19.12 |
kens | tolerate ? | 21:19.20 |
henrys | I get the impression he has more experience with pcl than pdf/ps but I might be mistaken. | 21:20.08 |
chrisl | Yes, he does. | 21:20.29 |
kens | Night all | 21:48.26 |
henrys | alexcher do the indeterminisms have associated bugs? | 23:05.43 |
| bbiab | 23:08.57 |
alexcher | henrys: no, I didn't file any bugs. I think, Marcos knows better about indeterminisms and SEGV in the current code base. | 23:13.22 |
| Forward 1 day (to 2011/11/04)>>> | |