| | <<<Back 1 day (to 2013/03/17) | 2013/03/18 |
| qwe | What are the licensing options for using mupdf in a commercial android app? | 06:20.26 |
| kens | Great. this morning Avast doesn't like genarch.exe :-( | 09:13.55 |
| chrisl | kens: possibly time for a new AV solution? | 09:28.56 |
| kens | chrisl I'm getting fed up of it certainly | 09:29.07 |
| peterrs | is the ghostpdl git repository down? i'm unable to clone git://git.ghostscript.com/ghostpdl.git | 10:38.45 |
| kens | Seems to beOK to me | 10:39.00 |
| | THough I've not tried cloning recently | 10:39.14 |
| | Hmm, thinks can you use anonymous git: or does that require a suer ? | 10:39.37 |
| | s/suer/user | 10:39.46 |
| | tor8 ping | 10:40.41 |
| tor8 | kens; hi. | 10:41.52 |
| kens | peterrs is asking about the Git repository | 10:42.05 |
| | It seems OK to me, can anonymous users use the git:// protocol ? | 10:42.21 |
| peterrs | sure, it's readonly-mode ? | 10:42.37 |
| tor8 | kens: yes. the git:// protocol is read-only and open to anonymous users. | 10:43.21 |
| kens | OK well the repository seems OK to me, though I've not tried a clone | 10:43.39 |
| tor8 | kens: if git:// doesn't work, http:// should but may be less efficient | 10:43.40 |
| | cloning works for me. what error are you getting? | 10:44.40 |
| peterrs | Cloning into 'ghostpdl'... fatal: unable to connect to git.ghostscript.com: git.ghostscript.com[0: 184.73.189.105]: errno=No error | 10:44.56 |
| | tried with http also, but nothing happens.. just displays "Cloning into 'ghostpdl'" (wait around 5 minutes, but nothing indeed happens) | 10:45.27 |
| tor8 | have you maybe got a firewall that blocks 9418? | 10:45.50 |
| kens | sounds more like a problem contacting the server than a specific Git problem | 10:45.53 |
| peterrs | probably | 10:45.56 |
| tor8 | cloning by http can be slow without much progress, but not five minutes slow | 10:46.25 |
| | cloning downloads about 120M of data | 10:46.42 |
| peterrs | true, i'm on a 1-gbit connection so | 10:46.46 |
| | i'm probably firewalled, i grabbed the source yesterday, but automated without the git tag's is going to be a pain | 10:47.16 |
| | thanks for the help guys | 10:47.31 |
| tor8 | peterrs: hmm, I'm not able to clone via http | 10:48.30 |
| | so there may be something wrong with that setup | 10:48.40 |
| peterrs | hmm | 10:49.06 |
| tor8 | git clone on my mac stops after a few seconds without an error message and without creating a repository :( | 10:50.51 |
| | on linux it's still chugging along. the .git directory is growing in size so that indicates something happening | 10:51.30 |
| peterrs | odd, i'm not on linux right now but guess i could fire up a vm and test | 10:52.12 |
| tor8 | git 1.7.2.5 managed to successfully clone on linux | 10:55.04 |
| peterrs | yes, i was successfull with http:// on ubuntu 12.10 but not on windows 7 with git 1.8.. http version that is | 11:00.28 |
| paulgardiner | Robin_Watts, tor8: commit needing reviewing on paul/master when you have a moment | 11:12.54 |
| Robin_Watts | ok | 11:13.07 |
| | paulgardiner: Looks good to me. | 11:26.10 |
| paulgardiner | ta | 11:26.17 |
| henrys | paulgardiner: well it is my wife's first fast day, I hope my ducking reflexes are still good. | 13:56.51 |
| paulgardiner | henrys: :-) Strangely, I've not noticed increased irritability. | 13:58.03 |
| | But then I haven't been watching someone else eat. You might want to eat in secret. | 13:59.24 |
| kens | Hiding sounds like a fine idea to me | 14:00.22 |
| paulgardiner | henrys: 5/2, or is she joining in with your monthly fast day? | 14:00.24 |
| henrys | paulgardiner:she watched the documentary and decided on 5/2 | 14:00.47 |
| Robin_Watts | tor8: ping | 14:35.26 |
| tor8 | Robin_Watts: hi | 15:32.06 |
| | back from vacation now? | 15:32.11 |
| Robin_Watts | I am. | 15:33.21 |
| | So, a mupdf customer got in touch last week, and complained that we weren't clipping tilings. | 15:34.54 |
| | and having done some tests this morning, it looks to me like that although we don't explicitly clip tilings (no work is done in begin_tile to clip the tiles) we really do clip tilings as they are enclosed in clippaths. | 15:36.11 |
| | and the clippaths handle the completely clipped case. | 15:36.26 |
| | I'm wondering if that breaks down when we have nested tilings though. | 15:36.44 |
| tor8 | IIRC we render tiles to a "tile buffer" which is unclipped, then that is repeatedly stamped out over the surface that needs painting | 15:41.38 |
| | now if all we have is one big tile that covers the page with no repeats, we have logic to detect that in the xps and pdf interpreters so we can draw those without using actual tile device calls. so those cases should end up rendering with clipping. | 15:42.55 |
| Robin_Watts | yes. | 15:45.01 |
| | I think the case they are wibbling about is when they have an area to be covered in tiles, and it turns out that for the given region of the displaylist that they are rendering, the area is completely clipped away. | 15:46.07 |
| | I believe they are claiming that we still draw the tile, only to then not use it at all. | 15:46.38 |
| tor8 | Robin_Watts: yeah. that can happen since the decision to render a tile or not happens in the interpreter which doesn't (and shouldn't) know about the clipping area | 16:05.42 |
| | still, the display list callback ought to be able to be smarter there | 16:05.59 |
| Robin_Watts | tor8: As far as I can see, every possible call to BEGIN_TILE/END_TILE is wrapped in some form of clip. | 16:06.29 |
| tor8 | yes. there's an implicit clip for each tile in the pdf spec. | 16:06.56 |
| Robin_Watts | so the display list OUGHT to be able to completely skip it, and in my tests it does. | 16:06.57 |
| | both xps and pdf, this is. | 16:07.04 |
| tor8 | and similarly in xps | 16:07.14 |
| Robin_Watts | So until I get a file from them that shows this, I think I'm going to ignore it. | 16:07.25 |
| | but this has spun 2 possible things out... | 16:07.47 |
| | 1) We are a display list, not a display tree. | 16:08.00 |
| | It would be nicer if we were a display tree, cos we could skip clips/tiles/groups etc wholesale at playback time. | 16:08.39 |
| | rather than having to step through them. | 16:08.44 |
| | 2) We could store tiles in the cache. | 16:09.07 |
| mvrhel_laptop | hi kens | 16:09.29 |
| kens | hi mvrhel_laptop | 16:09.38 |
| mvrhel_laptop | in your email you said you attached a pdf file? | 16:09.51 |
| kens | Did I ? oops.... | 16:10.01 |
| | I cna send you one, or you can just grab the PS file from teh bug report and make your own | 16:10.18 |
| mvrhel_laptop | kens: ok. I will grab the eps and generate myself | 16:10.49 |
| | doing the line change that you suggested | 16:11.00 |
| ray_laptop | chrisl: I noticed that you added $(II)$(DEVSRCDIR)$(D) to the GLI_= macro definition, but what about the devices/vector and devices/rinkj don't we need to be able to find those headers as well ? | 16:11.06 |
| mvrhel_laptop | I suspect there is an encoding issue here | 16:11.07 |
| kens | Its a very small file, its sets a sort of Lab space (offset so range is 0->255) and then fills a rectangle with a colour in that sapce | 16:11.23 |
| | I'm assuming its somethign about the rangbe offset that is causing the problem | 16:11.41 |
| | But I'm kind of in the dark, and can't read ICC profiles directly... | 16:12.04 |
| mvrhel_laptop | kens: yes. that is probably the issue. I will beat on it a bit now | 16:12.12 |
| kens | (unloike TrueType fonts) | 16:12.12 |
| | OK thanks Michael | 16:12.18 |
| | If you want me to make files, let me know, its easy enough. | 16:12.32 |
| | I'm chasing Marcos's 'missing output' problem at the moment though | 16:12.45 |
| mvrhel_laptop | kens: I should be all set | 16:12.47 |
| chrisl | ray_laptop: no, those are handled in devs.mak. We only need DEVSRCDIR because of the display device - it's the only device with definitions accessed directly from the interpreter | 16:13.13 |
| mvrhel_laptop | kens: I am certain the range is the issue. seeing [0 100 0 255 0 255] | 16:16.07 |
| ray_laptop | chrisl: OK. Thanks. BTW, I don't think you need the trailing $(D) (the others in lib.mak don't use that for the -I directories -- they _do_ define things like GLSRC=$(GLSRCDRC)$(D) | 16:16.36 |
| chrisl | ray_laptop: good point, thanks - I'll remove it in a second. | 16:17.41 |
| Robin_Watts | tor8: So, I had an idea about 1). | 16:17.46 |
| ray_laptop | chrisl: I don't think it does any harm | 16:18.03 |
| chrisl | No it is benign, but inconsistent....... | 16:18.23 |
| Robin_Watts | Rather than changing to be a display tree, we could just add a 'skip' pointer to the begin_tile (and other) nodes. | 16:18.40 |
| | If the tile is clipped out entirely we just update the list pointer to the skip value. | 16:19.34 |
| | (hmm, that would have bad effects on the progress counter, I think, but that may be soluble) | 16:20.28 |
| ray_laptop | Robin_Watts: so when you finish the definition of the tile, you go back and update the 'skip' pointer ? | 16:20.35 |
| Robin_Watts | ray_laptop: Yes. When building the display list, we already keep a stack of things for clips etc. | 16:21.05 |
| ray_laptop | Robin_Watts: seems to me like the progress counter would just jump ahead -- as if it were particularly easy to render | 16:21.15 |
| Robin_Watts | ray_laptop: The progress counter is done by counting how many things we'd done out of the number of items in the list. | 16:21.53 |
| ray_laptop | no body complains when the progress counter moves to quickly :-) | 16:21.54 |
| Robin_Watts | when we skip forwards, we don't know how many things we just skipped. | 16:22.05 |
| | linked list etc. | 16:22.18 |
| ray_laptop | Robin_Watts: I see -- so along with skip pointer, you'd need a skip count ? | 16:22.21 |
| Robin_Watts | ray_laptop: Yeah. | 16:22.28 |
| | There is no technical problem with that, it's more a problem of whether that's going to bloat our display list node size. | 16:23.22 |
| mvrhel_laptop | kens are you still here? | 16:31.04 |
| | so I see what is going on in the graphics library that makes things work. but I am not sure how you want to handle this in the pdfwrite case | 16:31.36 |
| kens | mvrhel_laptop : yes sorry nipped off to grab a coffee | 16:32.42 |
| mvrhel_laptop | np. do you want me to write up what I found in an email or talk about it now | 16:33.03 |
| kens | Hmm, up to you, but an email might be easier for me to refer to | 16:33.22 |
| | Although this is a linework case I also haveto consider the image case | 16:33.37 |
| mvrhel_laptop | kens: ok I will do that. it is a range issue. and I don't know how to handle in pdfwrite case | 16:33.54 |
| | and images would be particularly ugly | 16:34.00 |
| kens | Nor do I to be honest | 16:34.05 |
| | I would prefer not to modify the colour component values, but if I have to... | 16:34.19 |
| mvrhel_laptop | since pdf does not have the concept of range it is going to be messy | 16:34.47 |
| kens | Ah, I see.... | 16:34.57 |
| | Well I have dode to munge the colour values in linework and image data, so its probably possible to solve | 16:35.37 |
| mvrhel_laptop | we could add in some special tag though into our internal icc profiles | 16:35.40 |
| | but that would not work for other renderers | 16:35.55 |
| kens | I'm not sure how that helps, maybe I should read your mail first | 16:35.58 |
| | Oh I see, when reading our PDF, no that's not going towork | 16:36.11 |
| mvrhel_laptop | right :) | 16:36.19 |
| kens | It has to be valid with Acrobat at least | 16:36.24 |
| mvrhel_laptop | and V2 profiles are very restricted on what they can do | 16:36.41 |
| | let me send you an email to review | 16:37.19 |
| | then if you need anything more from me let me know | 16:37.28 |
| kens | I think I'm going to need trhe background | 16:37.32 |
| tor8 | Robin_Watts: right. skip pointer sounds good. | 16:46.22 |
| Robin_Watts | Any thoughts on 2? | 16:46.46 |
| | (storing rendered tiles in cache) | 16:46.55 |
| tor8 | what would we use as the lookup key to cached tiles? | 16:47.31 |
| | remember, we should ideally not make things significantly worse for the non-display-list case | 16:47.56 |
| Robin_Watts | tor8: I hadn't thought that far :) | 16:48.56 |
| | We'd need to pass something extra into the begin_tile function. | 16:50.50 |
| | A void *id, which would be NULL in the non-display list case. | 16:51.25 |
| | and which could be a node pointer in the non-NULL case. | 16:51.38 |
| | Or we could implement a 1 place cache within the display list node itself. | 16:58.45 |
| | tor8: He's just sent the document he's seeing the problem on to support. | 17:06.11 |
| | There is only 1 tile in the document. It's repeated across the entire background many times. | 17:06.46 |
| | So whatever part of the document he draws, it will be rendered. | 17:07.15 |
| | I suspect the issue he has is that he's redrawing lots of small sections of the document (lots of partial redraws) and that's causing the tile to be rendered for each one. The cache would solve this. | 17:08.01 |
| | Using a void *id which is set to the node pointer could potentially give us trouble in that when the list is freed, a new node might be allocated in the same place and give us a false positive hit. | 17:10.27 |
| henrys | hmmph gcc.gnu.org is down for me. | 17:18.08 |
| Robin_Watts | For me too. | 17:20.35 |
| henrys | marcosw:I wonder if SSD upgrades might be preferred to new nodes. Although I don't know if the other nodes will speedup as much as macpro | 17:30.13 |
| marcosw | marcosw: I don't think so. The other nodes have at most 8 cores available and a hard drive has no problem keeping all 8 nodes busy, at least when piping to md5sum. | 17:31.11 |
| | it would definitely speed up running bmpcmp, but that doesn't need a speed up. | 17:31.33 |
| ray_laptop | marcosw: I closed bug 693703 as invalid. We've seen this before and I don't think there is anything we can do. This is at least the 5th time I've analyzed one of these, looking for a possible solution | 17:31.52 |
| mvrhel_laptop | kens: so I did a little testing. I think you will only need to adjust the graphic object data. The image data should be OK. I will attach a file to show | 17:31.56 |
| marcosw | if you run htop on your x6 system during a cluster run you'll see the cores are 100% busy. | 17:32.00 |
| mvrhel_laptop | the graphic fill colors that is | 17:32.07 |
| kens | thanks michael | 17:32.30 |
| | I have to go cook, I'll read the mail this evening and try it out | 17:32.46 |
| ray_laptop | marcosw: the only thing I didn't try was changing the image painting to use the 'any part of pixel' rule, but that causes many other files to break :-( | 17:32.56 |
| marcosw | that wasn't the case on your macpro, the 16 cores were not constantly in use before the upgrade to the SSD card. | 17:33.02 |
| henrys | marccosw:okay | 17:33.24 |
| ray_laptop | henrys: peeves already has an SSD (albeit a tiny one) for the system and for /tmp | 17:33.38 |
| marcosw | ray_laptop: thanks for looking at the issue; I wouldn't have bothered opening a bug if it hadn't been reported by an important customer. | 17:33.53 |
| ray_laptop | that's why no room on /tmp used to be a problem on peeves | 17:34.15 |
| | marcosw: not your fault. I just wish there was a way to get at the actual creator of the data (probably some Windows app). | 17:35.06 |
| kens | some crappy cad package | 17:36.03 |
| ray_laptop | kens: yeah, probably | 17:39.03 |
| marcosw | ray_laptop: I know it's a horrible hack, but could we somehow detect when this "problematic method of painting" is used and not draw anything for those objects? I think all of the files I've run across would be correct if nothing was painted. Presumably there could be a command line option to control this. | 17:40.16 |
| adnap | Is it possible to print a PDF with MuPDF? If not, how can I print a PDF? | 18:11.10 |
| Stachelritter | hello | 18:43.47 |
| | how I can add a copy protection for a PDF, I can't find it in the documentation | 18:44.24 |
| Robin_Watts | adnap: hi | 19:11.01 |
| | adnap: MuPDF knows how to render to bitmaps. It doesn't currently know how to render to a bitstream suitable for sending to a printer. | 19:11.37 |
| | Are you using the windows/linux app? | 19:11.46 |
| joe9 | I want to convert a pdf document to text. pdftotext is the first link on google. I use mupdf. wanted to check if there is any mupdf utility that can do the same from the command line. | 21:02.42 |
| kens | GS and MuPDF can botht do this | 21:03.04 |
| joe9 | kens, sorry for the bother. I am checking on how MuPDF can do it. using mupdfdraw? | 21:04.25 |
| kens | not using mupdfdraw, possibly mupdfclean ? I am not the resident expert :-( | 21:04.45 |
| tor8 | kens: joe9: mudraw with appropriate -t flags | 21:06.30 |
| joe9 | tor8, thanks | 21:07.35 |
| kens | Like I said, not the resident expert.... | 21:09.12 |
| joe9 | tor8: mudraw -t note.pdf [1-5], printed some blank lines. | 21:09.44 |
| tor8 | joe9: it doesn't do any OCR, so if your PDF is a bitmap of a scanned document it won't work | 21:11.51 |
| joe9 | ok, thanks. | 21:12.05 |
| | tor8, I got the document using print-> microsoft Document Image Writer -> .tif file -> tiff2pdf -> .pdf? | 21:14.13 |
| | will it help to print to a .ps file instead? | 21:14.30 |
| kens | no | 21:14.34 |
| joe9 | kens, any pointers on how to go about it, please? | 21:15.22 |
| kens | Hmm, what is the source document, IO was thinking an image but maybe not ? | 21:15.35 |
| joe9 | kens, the source document appears to be a scanned pdf document. | 21:16.18 |
| | but, I am not sure. it is embedded in an app. | 21:16.37 |
| kens | If it is scanned then it is images, so you must use an OCR package to find the text | 21:16.37 |
| joe9 | kens, yes, I think it is scanned. | 21:16.51 |
| | thanks. let me check for OCR packages. any recommendations, please? | 21:17.08 |
| kens | then I'm afraid there is nothing that you can do except use OCR (Optical Character Recognition) | 21:17.18 |
| | I am out of touch on these, so cannot recommend any | 21:17.42 |
| joe9 | kens, thanks. | 21:18.09 |
| | kens, just an fyi, I was able to get that stuff using tesseract. thanks for the pointer. | 21:51.35 |
| marcosw | Robin_Watts: you still about? perhaps jet lagged? | 23:47.10 |
| | Forward 1 day (to 2013/03/19)>>> | |
IRC Logs