| | <<<Back 1 day (to 2011/09/06) | 2011/09/07 |
| AlecTaylor | hi | 08:00.18 |
| chrisl | AlecTaylor: Hi | 08:01.49 |
| AlecTaylor | I'm here from MuPDF | 08:03.33 |
| | What's the best open-source library for analysing headers, footers & ToC using custom [written by me] algorithms? | 08:04.12 |
| | (in C or C++) | 08:04.23 |
| | More info: http://sourceforge.net/mailarchive/message.php?msg_id=28053119 | 08:06.20 |
| chrisl | What do you means by "analysing"? And PDF doesn't have "headers" or "footers" - it doesn't differentiate content like that. | 08:08.22 |
| kens | Well,it might, but only in tagged PDF. | 08:08.44 |
| AlecTaylor | That's what I'm analysing | 08:09.32 |
| | Using my custom algorithms | 08:09.35 |
| chrisl | Sorry missed the "generally" | 08:09.38 |
| kens | MuPDF and Ghostscritp can both extract text (up to a point) from PDF files, and can give you information about that text. | 08:09.47 |
| AlecTaylor | is a researcher | 08:09.48 |
| | kens: Is MuPDF better to use than PoDoFo? | 08:10.14 |
| kens | Neither is intended to allow you specifically to modify the PDF. However, if all you want to do is add hyperliokns you could reprocess the PDF with Ghostscript and add the hyperlinks using pdfmarks | 08:10.27 |
| | AlecTaylor : I'm not familiar with PoDoFo so I can't comment | 08:10.46 |
| AlecTaylor | kens: Is there an example somewhere you can link me where Ghostscript is utilised to do just that? | 08:11.26 |
| kens | AlecTaylor : I don't know of anyone using Ghostscritp to do this, so no. Not only that but the text extraction code is new, so I can't point to any examples of people using it. | 08:12.00 |
| | The text extraction in MuPDF has been around longer. | 08:12.19 |
| | I'm not sure how you would go about using MuPDF to add hyperlinks to an existing document. Not sure this is even possible at the moment, and Tor isn't online yet. | 08:13.09 |
| chrisl | I think it will depend on the level of access you need. The MuPDF architecture could make it easier to "hook in" at the graphics primitive level, which might better for your information *gathering*. | 08:14.46 |
| AlecTaylor | kens: Should I come back later when Tor is here? | 08:15.18 |
| AlecTaylor | is in a different timezone, so please give an "he will be online in 7 hours" type info | 08:15.36 |
| | chrisl: Graphics primitive level? | 08:15.52 |
| chrisl | Fill, stroke, draw glyph etc | 08:16.15 |
| kens | Tor will be arond shortly. Generally within the next hour. He is based in Sweden but is a late starter | 08:16.20 |
| AlecTaylor | Sure | 08:17.02 |
| AlecTaylor | is in Australia | 08:17.05 |
| kens | I think all you want is text ? Why not play quickly with teh text atraction of MuPDF and Ghostscript and see if it looks suitable ? | 08:17.44 |
| | 'the text extractio' | 08:17.56 |
| | oh good grief.... | 08:18.02 |
| kens | can't type this morning | 08:18.08 |
| AlecTaylor | :P | 08:18.35 |
| | Just downloaded this: http://code.google.com/p/mupdf/downloads/detail?name=mupdf-0.9-windows.zip - Seems quite limited, just a couple of .exe's? - What's the library backend? | 08:19.02 |
| kens | I think you want the source if you want to play with the library, but the executables will give you an easy way to see if it'll do what you want. | 08:19.41 |
| | Now I need to remember how to get text out of it.... | 08:20.04 |
| | Possibly pdfextract | 08:20.28 |
| | Hmmm, no.... | 08:21.31 |
| | Ah, pdfdraw -t or -tt | 08:22.13 |
| AlecTaylor | Hmm, actually this library I just found doesn't seem to bad: https://github.com/galkahana/PDFWriterSamples/blob/master/Parsing/Parsing.cpp | 08:23.09 |
| | What do you think? | 08:23.12 |
| kens | That seems to be an example of using a different library... | 08:24.14 |
| | Seems to me it still leaves the problem of updating the PDF with the hyperlinks. | 08:25.04 |
| AlecTaylor | Yeah, but can the libraries you're talking about provide the same functionality? | 08:25.22 |
| kens | I would imagine so, I'm not at all certain, since I can't figure out what that code is doing quickly. | 08:26.20 |
| | Both MuPDF and Ghostscript can extract text, give you information about it (position, size, font, colour, text rendering mode etc) and can gracefully fall through a series of attempts to give you meaningful information about the text (Unicode values, Encoding, character code). | 08:27.27 |
| | I presume from that you could, most of the time, create the information you want., ie the hyperlinks. | 08:28.10 |
| | Whether they are easier to use is not obvious. However, since both of them output to file formats you might ifnd it easier to use them as external processes than linking to the libraries directly. | 08:28.46 |
| AlecTaylor | hmm | 08:29.15 |
| AlecTaylor | is thinking to learn ghostscript | 08:29.23 |
| kens | wishes Tor would turn up to get involved. | 08:30.02 |
| AlecTaylor | aye | 08:35.25 |
| kens | chrisl in case I miss Robin_Watts when he comes on, can you tell him that his commit of the xcode project seems (bizarrely) to have caused seven files to start seg faulting with the plank device. (Robin may even read the logs ;-) | 08:37.09 |
| chrisl | kens: I'll make sure he knows, yes. That makes no sense, though........ | 08:46.52 |
| marcosw_ | kens: that wasn't Robin_Watts' commit. I added those files before his commit, so his was the first one that processed the files. | 08:49.05 |
| marcosw_ | is wondering what he's doing up at this time... | 08:49.57 |
| | night all | 08:50.26 |
| AlecTaylor | tor8: We were waiting for you! | 09:11.27 |
| | Question: What is the best open-source library for analysing PDF headers, footers & ToC using custom [written by me] algorithms? â More info: http://sourceforge.net/mailarchive/message.php?msg_id=28053119 | 09:11.57 |
| tor8 | morning | 09:13.20 |
| kens | tor8 you should probably review the morning irc logs | 09:13.46 |
| tor8 | is reading the irc logs | 09:14.03 |
| AlecTaylor | YAY! | 09:15.13 |
| tor8 | AlecTaylor: you've certainly got a big job ahead of you, regardless of which library you decide to use | 09:15.49 |
| | you can certainly use the MuPDF text extraction as a start | 09:16.06 |
| AlecTaylor | Indeed I do. So I want to make it as easy as possible on myself | 09:16.15 |
| | thus I should start with a good base library | 09:16.28 |
| tor8 | I've got some new code in MuPDF sitting on a branch that attempts to do a better job of sorting and assembling the pieces | 09:16.39 |
| AlecTaylor | tor8: Is MuPDF the best at this task? | 09:16.40 |
| tor8 | we don't look at the structured tags at all in mupdf, but I'm not aware of any others that do either | 09:17.18 |
| kens | They are rarely useful, even if present | 09:17.43 |
| AlecTaylor | has been looking at Hummus, Libpdfxx, GhostScript, MuPDF and PoDoFo | 09:17.45 |
| tor8 | I don't think it matters much which library you use in terms of capability, all you'll get is a listing of the text on a page with positioning information | 09:18.16 |
| kens | Time for me to go, back in a couple of hours. | 09:19.15 |
| tor8 | so I'd go with the one you feel most comfortable using as-is or most comfortable modifying | 09:19.18 |
| AlecTaylor | hmm' | 09:20.42 |
| tor8 | AlecTaylor: check out the 'text' branch from git://git.ghostscript.com/user/tor/mupdf.git | 09:22.58 |
| AlecTaylor | I can't find the text branch: http://git.ghostscript.com/user/tor/mupdf.git/ | 09:24.08 |
| tor8 | git clone http://git.ghostscript.com/user/tor/mupdf.git | 09:25.27 |
| | then "git checkout text" | 09:25.33 |
| | and I think you need to back out the latest commit to get it to actually work (it's an experimental development branch) | 09:26.13 |
| | so "git reset --hard HEAD^" after that | 09:26.20 |
| AlecTaylor | is at University without git access. | 09:26.57 |
| | tor8: Can you pastebin it for me? | 09:27.05 |
| tor8 | http://ghostscript.com/~tor/stuff/textdevice/newspaper.html is what we can do from http://ghostscript.com/~tor/stuff/textdevice/newspaper.pdf page 1 | 09:27.31 |
| | that's the text sorted into blocks/paragraphs and associated with styles. there is a lot more positioning information available than you can see in the html though. | 09:28.57 |
| AlecTaylor | Wow, that's horrible | 09:29.12 |
| | You should read the latest ICDAR conference papers | 09:29.20 |
| | They've solved it :P | 09:29.34 |
| | (without bad layout) | 09:29.39 |
| tor8 | it's not an attempt at replicating the page, I'm just showing how the text has been disassembled into the correct parts without merging columns and other mishaps that can easily happen | 09:30.55 |
| | do you have a link to those papers? | 09:31.09 |
| AlecTaylor | Sure | 09:31.32 |
| | Give me a sec | 09:31.34 |
| tor8 | look at that newspaper and figure out an algorithm that puts all the paragraphs into a logical linear reading order and I'll be more than happy to hear it | 09:32.40 |
| AlecTaylor | I saw quite a few implementations | 09:33.59 |
| | http://dl.acm.org/citation.cfm?id=1998079 | 09:36.49 |
| SantoSoetarmin | Hi All | 09:40.40 |
| | i want to ask about using muPDF in Android | 09:40.58 |
| tor8 | hello | 09:41.18 |
| SantoSoetarmin | i'm using Samsung Galaxy Tab, the memory keep increasing when navigating page | 09:41.33 |
| | hi tor8 | 09:41.36 |
| tor8 | do you call pdf_age_store between pages? | 09:42.03 |
| SantoSoetarmin | no | 09:42.22 |
| | i using the source code from http://code.google.com/p/mupdf/downloads/list | 09:42.55 |
| tor8 | then that's most likely the reason the memory use increases | 09:42.59 |
| SantoSoetarmin | http://code.google.com/p/mupdf/downloads/detail?name=mupdf-0.9-source.tar.gz&can=2&q= | 09:43.03 |
| | i just add pdf_age_store(xref->store, 3); in end of Java_com_artifex_mupdf_MuPDFCore_gotoPageInternal | 09:43.34 |
| | but still same | 09:43.37 |
| | i get it from http://bugs.ghostscript.com/show_bug.cgi?id=692278 | 09:44.23 |
| tor8 | Then you'll have to ask Robin_Watts | 09:47.34 |
| Robin_Watts | SantoSoetarmin: How are you measuring the memory use? | 09:47.35 |
| SantoSoetarmin | i using some script in java file, the MemoryInfo | 09:48.16 |
| | almost all the time, memory used | 09:48.52 |
| | but there is a case, that when navigating the pdf file, the memory is increasing | 09:49.24 |
| Robin_Watts | SantoSoetarmin: Can you open a bug please, with everything I need to reproduce the problem. | 09:49.54 |
| SantoSoetarmin | ok | 09:50.18 |
| | 09-07 16:14:02.400: INFO/before(10229): mem: 424304640 | 09:50.20 |
| | 09-07 16:49:35.840: INFO/before(10229): mem: 401223680 | 09:50.20 |
| | 09-07 16:49:37.200: INFO/before(10229): mem: 400453632 | 09:50.20 |
| | 09-07 16:49:38.520: INFO/before(10229): mem: 397611008 | 09:50.20 |
| | 09-07 16:49:39.850: INFO/before(10229): mem: 399568896 | 09:50.20 |
| | 09-07 16:49:41.080: INFO/before(10229): mem: 395956224 | 09:50.20 |
| | 09-07 16:49:42.060: INFO/before(10229): mem: 388345856 | 09:50.21 |
| Robin_Watts | I need source code, an example file, and an exact set of instructions. | 09:50.26 |
| SantoSoetarmin | ok thanks Robin an tor8 | 09:50.43 |
| Robin_Watts | Bear in mind that the java sections of the code will appear to leak until they hit a garbage collect, then the level will drop. | 09:51.07 |
| | You could try putting a System.gc(); call in somewhere that gets called every so often. | 09:51.47 |
| SantoSoetarmin | will try that then | 09:52.14 |
| | Hi Robin | 09:56.08 |
| | i'm trying your advice about garbage collection | 09:56.23 |
| | currently the memory not consume like before | 09:56.44 |
| | i will update, after testing some pdf file | 09:57.03 |
| Robin_Watts | Fab. | 09:57.08 |
| SantoSoetarmin | thanks Robin | 09:57.12 |
| | :) | 09:57.13 |
| Robin_Watts | np. | 09:57.15 |
| tor8 | Robin_Watts: when are you getting in tomorrow? | 09:58.11 |
| Robin_Watts | Plane lands 13:55. | 09:58.24 |
| | and you? | 09:58.32 |
| | Checkin in 2 mins. | 09:58.38 |
| tor8 | mine doesn't land until 17.35 | 09:58.54 |
| | and I just saw the date for flying back home >.< | 09:59.30 |
| Robin_Watts | hehe | 09:59.37 |
| | Helen is *not* pleased about that. | 09:59.45 |
| tor8 | good thing I'm not superstitious :) | 09:59.50 |
| Robin_Watts | 707 pcl tests down, no differences foun. | 10:27.49 |
| | d | 10:27.54 |
| | marcosw_: I'd like to understand how come your tests are producing differences, when mine aren't. | 10:30.14 |
| | Could you generate a pair of differing bitmaps from your test please and put them somewhere I can look at them please? | 10:30.44 |
| | rebooty | 11:49.53 |
| | Hmm. Just going to try some tests with ghostbot. | 12:42.33 |
| kens | Is it not working >? | 12:42.45 |
| Robin_Watts | ask a question is <REPLY>Don't ask to ask, just ask. | 12:42.49 |
| kens | Ah. | 12:43.02 |
| Robin_Watts | ask a question | 12:43.03 |
| | OK, so ghostbot isn't doing that :) | 12:43.14 |
| kens | Hmm, this is nasty, one for henrys. If I render this PCL file at different resolutions, I get different results. I didn't realise that could happen in PCL. | 12:44.47 |
| Robin_Watts | ghostbot claims to be infobot-1.5.3 | 12:45.19 |
| | The latest infobot I can find on the web is 0.49... | 12:45.29 |
| kens | Hmm, doesn't sound good | 12:45.38 |
| | wikipedia says 'may forks were made' for infobot | 12:46.23 |
| Robin_Watts | This bot is based upon blootbot, which was a fork of infobot-0.44.2 by | 12:47.12 |
| | Kevin Lenzo <lenzo@cs.cmu.edu>, which is now officially rebranded back to | 12:47.14 |
| | infobot! The basis of infobot is still there but _many_ wild features have | 12:47.16 |
| | been added. Along the way, many issues were spotted in the original | 12:47.18 |
| | infobot source and fixed in this version. Many new bugs have been added as well. | 12:47.20 |
| | Thanks to kevin for bringing infobot in the first place. | 12:47.22 |
| kens | Wikipedia also says the latest stable release is 1.5.3, March 15 2011 | 12:47.36 |
| Robin_Watts | But if you follow that link you get to sourceforge, and that says 0.45.3 | 12:48.45 |
| kens | Yes, I was about to say that. | 12:48.56 |
| Robin_Watts | ghostbot: tests is <REPLY>testing | 12:50.06 |
| ghostbot | okay, Robin_Watts | 12:50.06 |
| Robin_Watts | ghostbot: ask a question is <REPLY>Don't ask to ask, just ask. | 12:50.28 |
| ghostbot | Robin_Watts: okay | 12:50.28 |
| Robin_Watts | Can I ask a question? | 12:50.33 |
| | ask a question | 12:50.43 |
| | ghostbot: Can I ask a question? | 12:51.03 |
| | ghostbot: ask a question | 12:51.10 |
| ghostbot | Don't ask to ask, just ask. | 12:51.10 |
| Robin_Watts | ghostbot: ask a question? | 12:51.13 |
| ghostbot | Don't ask to ask, just ask. | 12:51.13 |
| kens | henrys won't be please, I just passed two of my bugs to him :-) | 12:58.16 |
| Robin_Watts | Something is deleting our irc logs after a month. | 13:06.17 |
| | But I don't know what. | 13:06.26 |
| tor8 | Robin_Watts: I also noticed that it sometimes truncates the last couple of messages in a day | 13:07.54 |
| Robin_Watts | tor8: We have a cron job that runs every 5 minutes. | 13:08.20 |
| | That cron job converts the current irc log to html. | 13:08.35 |
| tor8 | I think it maybe misses the last 5 minutes before a log file switch | 13:08.56 |
| Robin_Watts | So if the log runs at 11:56 and then 00:01, we don't convert any messages that occur during that time. | 13:09.01 |
| | or rather we only get the 00:00 to 00:01 ones. | 13:09.13 |
| kens | chrisl bug #692491 (new) is assigned to alex, but looks like it shuold be yours. | 13:09.14 |
| tor8 | right | 13:09.16 |
| | that sounds like what I've been seeing | 13:09.26 |
| Robin_Watts | tor8: It can probably be fixed with a bit of shell script magic. | 13:09.57 |
| | (i.e. if the date is in the first 5 minutes of the day, reconvert the old one too) | 13:10.20 |
| | And I'd like to split the logs into a heirarchical year/month/day format too. | 13:10.47 |
| | but first off, I need to stop whatever is eating the logs at a month old :( | 13:11.00 |
| tor8 | that would be a nice feature if we're going to keep them long :) | 13:11.05 |
| kens | Robin_Watts : its surely not a month ? I see logs back to July. Though no further than that, so they are vanishing. | 13:11.30 |
| Robin_Watts | kens: OK, 2 months :) | 13:12.32 |
| marcosw_ | Robin_Watts: I've put a plank/pamcmky4 set of files into ~marcos/plank on casper. These show a md5sum, but I haven't looked at the bitmap (but gzip'd one is 1667076 bytes and the other 1767467, so I presume it's not a trivial difference). | 13:14.53 |
| Robin_Watts | marcosw_: Thanks. | 13:15.04 |
| | lunchtime. | 13:15.09 |
| marcosw_ | I have to run to school, to setup for my presentation. | 13:15.25 |
| chrisl | kens: I'll have a look at 692491 - it seems barely credible...... | 13:21.56 |
| kens | The performance degradation is amazing. Far more than he suggests. | 13:24.41 |
| chrisl | *more* than he suggests? I don't have any of the fonts he's listed :-( | 13:25.13 |
| kens | Well he hasn't given much to go on, but the time he quotes is a factor of 450 | 13:26.02 |
| chrisl | Oh, I see - I thought you meant you'd tested it, and it was even worse that 20 seconds to 2.5 hours | 13:26.45 |
| kens | Nah, I don't have the fonts either. | 13:26.55 |
| | But they seem to be in some distro or toher | 13:27.04 |
| | http://rpm.pbone.net/index.php3/stat/4/idpl/15620300/dir/opensuse/com/sazanami-fonts-20040629-196.3.noarch.rpm.html | 13:27.36 |
| chrisl | Yes, I can get them on Ubuntu, it looks like | 13:28.11 |
| kens | Drat. AdobeSerifMM has a LenIV of 4 :-( | 13:29.48 |
| | That means I'm going to have to include decryption. | 13:30.09 |
| chrisl | kens: 692491 is memory management - if I have FAPI/Freetype bypass our "heap allocator" and go straight to the system malloc/free, it goes like greased lightning | 14:11.59 |
| kens | Hmmm.... | 14:16.53 |
| | One for Ray then ? | 14:16.58 |
| chrisl | I'm not sure. It could be that it's using an unsuitable allocator - I'll have a look, and probably ask Ray's advice. | 14:18.23 |
| | I actually thought the normal heap allocator basically went straight to the system malloc/free anyway, so clearly something more is going on | 14:19.49 |
| kens | Fair enough | 14:21.20 |
| chrisl | kens: if I switch FAPI/Freetype to use a chunk allocator instance, the first page renders in 1.2 seconds, when using the head allocator I killed it after 7 minutes! Seems worthwhile..... | 14:41.05 |
| kens | Yes, but I have no idea what the implications of that are. | 14:41.32 |
| Robin_Watts | What makes the head allocator so much slower? | 14:41.55 |
| chrisl | No idea. I thought it was the mutex lock/unlock, but building with nosync made no appreciable difference | 14:42.41 |
| | The gprof output shows: gs_heap_free_object() taking 99.85% of the time | 14:43.33 |
| | So, the difference *might* be that the chunk allocator is caching the free blocks, instead of immediately free-ing them back to the C library - but if that were the case, I would have expected the alloc method to feature highly as well. | 14:45.19 |
| Robin_Watts | chrisl: gs_heap_free_object can have to do a linear search in some cases. | 14:52.28 |
| chrisl | Robin_Watts: yeh, I was just looking at that. It might be that because it looks like Freetype is using lots of small memory allocations - which I think would really suit the chunk allocator. | 14:53.58 |
| Robin_Watts | I'd like to understand what that's doing at some point, but not today. | 14:54.44 |
| | henrys: Those devices *aren't* inverted. | 14:54.51 |
| | I have a page on a white background here, and the cmyk values are 0,0,0,0. Looks right to me. | 14:55.10 |
| chrisl | Robin_Watts: is that search just there so that we keep track of all the memory we've allocated and freed? I can't see any other reason for it | 14:56.11 |
| Robin_Watts | It searches through every allocated block, looking to see if it's found this one. | 14:57.51 |
| | If it does, it unlinks it from the doubly linked list, updates mmem->used and then frees it. | 14:58.27 |
| | If it just *assumed* that it was a valid block (i.e. set bp = ptr-1) then it wouldn't have to search for bp at all. | 14:58.56 |
| chrisl | Yeh, but remember the finalization in ghostscript releases all outstanding allocated memory, so we much track that somehow - I guess that doubly linked list is part of that. | 15:00.00 |
| Robin_Watts | That's not a problem. | 15:00.11 |
| | We can get to the doubly linked list easily. | 15:00.24 |
| | We take ptr, then do: np = &((gs_malloc_block *)ptr)[-1] | 15:01.00 |
| | Then fiddle with np->next and np->prev as appropriate. No searching required. | 15:01.24 |
| chrisl | Oh, I see - that code should probably only be there for debug builds, or maybe as a debug option then. | 15:01.54 |
| Robin_Watts | As a debug option, I reckon, yes. | 15:02.04 |
| | I may try fixing that later. | 15:02.13 |
| | unless you want to go first. | 15:02.22 |
| henrys | Robin_Watts:oh then I guess it is imagemagick - but michael had the same problem with photoshop wheat are you using? | 15:03.20 |
| | what are you using to look at the output? | 15:04.16 |
| chrisl | Robin_Watts: I think the only difficult part will be finding a spare command line option! I'd like to run it past Ray before making any changes in there, though. | 15:04.26 |
| | Oh, and I should pack at some point | 15:04.28 |
| henrys | Robin_Watts:anyway the missing graphics in pcl broke when you fixed the color procs. I suspect the rop device doesn't like cmyk color encode/decode. | 15:07.12 |
| Robin_Watts | henrys: I convert to png using imagemagick convert | 15:09.30 |
| henrys | I've organized the agenda into categories so you can more easily schedule naps, solitaire, adult movies etc. ;-) | 15:09.32 |
| kens | Oh boy! I got the date wrong, I thougth we were flyong on Friday.... | 15:09.39 |
| kens | runs off to prepare laptop | 15:09.50 |
| Robin_Watts | chrisl: I was thinking of a #define thing. | 15:10.22 |
| | I need to pack too. | 15:10.28 |
| chrisl | Robin_Watts: I was thinking of using "gs_alloc_debug", same as for writing over alloc'ed and freed memory. | 15:12.53 |
| Robin_Watts | Oh, what an ass. | 15:14.17 |
| | -sDEVICE=plank -sDEVICE=bmp16m | 15:14.30 |
| | no wonder my script wasn't finding any differences for pcl. | 15:14.46 |
| kens | :-) | 15:15.08 |
| | henrys I pushed a couple of PCL ones over to you. The rendering differs at different resolutions, and I've no idea if that is correct. Would you take a quick look please ? | 15:15.33 |
| kens | is grateful for the categorisation of the agenda | 15:16.11 |
| Robin_Watts | kens: I've seen pcl files that render very differently at different resolutions. | 15:17.14 |
| | I assumed that that was normal. | 15:17.22 |
| kens | I have no idea. The differences are profound though | 15:17.40 |
| henrys | kens:right I'll look. | 15:19.34 |
| kens | Thanks henrys | 15:20.03 |
| Robin_Watts | henrys: This problem gives the lie to the idea that only encode_color and decode_color are required, I think. | 15:27.14 |
| | My encode_color and decode_color methods are mirrors of each other; they simply map from cv[4] to a gx_color_value and back again, with no conversion (other than the fact that cv's are 16 bits and gx_color_value is 4 bytes orred together). | 15:31.14 |
| | Previously I had them converting from cmyk to rgb and back again. | 15:31.51 |
| | And that worked, but altered the cmyk values in some cases (which caused another lot of problems) | 15:32.27 |
| henrys | right and I guessed the rop device is expecting (incorrectly) RGB | 15:33.13 |
| | assuming everyhting else is correct PS/PDF etc. | 15:33.44 |
| | but that leaves as a mystery why pamcmyk4 is working | 15:34.28 |
| | perhaps it is using the deprecated "map" procedures? | 15:34.52 |
| Robin_Watts | It is. | 15:35.04 |
| | For now, I'll just change plank and planc to do the same thing. | 15:35.14 |
| henrys | okay the rop device does need the cmyk -> rgb how that gets done probably should be fixed to use the newer encode/decode procedures. | 15:36.07 |
| | but for now ... | 15:36.32 |
| | Robin_Watts, tor8:is there an incantation to run git reflog on the remote master? it works fine on my local repo can't get it to work with the remote. | 15:40.35 |
| Robin_Watts | henrys: What are you trying to do ? | 15:41.01 |
| henrys | well last night I was going to answer marcos' question I knew you had pushe and backed oout - but thought I'd like to see the transaction.. | 15:42.13 |
| Robin_Watts | git reflog lists the changes which a working set has gone through. The server is a bare repo, so no working set. Hence no reflog. (Maybe?) | 15:43.22 |
| | http://stackoverflow.com/questions/3876206/how-do-i-view-a-git-repos-recieve-history | 15:44.39 |
| | See answer 1. I was wrong. It's something we'd need to enable. | 15:44.52 |
| henrys | thanks | 15:45.04 |
| | probably not something we really need. | 15:47.01 |
| tor8 | henrys, Robin_Watts: should be easy enough to set, and useful to have in cases like last night | 15:54.01 |
| henrys | fine by me... | 15:54.51 |
| tor8 | done. | 15:57.01 |
| Robin_Watts | I've fixed the device... and now I'm not getting any images at all. | 15:58.54 |
| henrys | I looked at a lot of fts files and didn't see any images in the current code. | 16:00.37 |
| Robin_Watts | Any greyscale images will appear completely transparent in the current code. | 16:01.30 |
| | because I'll give a CMYK value with C,M,Y =0 and K = whatever, and the code will interpret that as RGB and ignore the non-zero one. | 16:02.16 |
| | By =0 I mean = 0 | 16:02.43 |
| | chrisl: http://ghostscript.com/~robin/patch.txt | 16:04.56 |
| chrisl | Robin_Watts: I'll give it a try, thanks | 16:05.43 |
| henrys | I didn't think any of the images I looked at (fts.0060) which are you looking at? | 16:08.15 |
| Robin_Watts | ../ghostpcl/tests\pcl\ieee0796.pcl | 16:08.40 |
| mvrhel2 | good morning | 16:12.01 |
| Robin_Watts | morning | 16:12.09 |
| chrisl | Robin_Watts: that patch makes quite a difference - more than changing to the chunk allocator. As I said, it's really down to Ray, though. | 16:14.00 |
| Robin_Watts | chrisl: It could be huge speed boost everywhere. | 16:14.19 |
| | but yes, need to talk to ray. | 16:14.32 |
| henrys | Robin_Watts:why are transparent gray images not a problem in the ps/pdf testing? | 16:16.23 |
| Robin_Watts | transparent grey images aren't the problem. | 16:17.05 |
| | In ps/pdf everything correctly respects the colorspaces. | 16:17.20 |
| | so I encode and decode cmyk to and from color, and everyone is happy. | 16:17.35 |
| | In PCL, we are forced to turn stuff to rgb. | 16:17.58 |
| | and that's where it goes wrong. | 16:18.07 |
| henrys | I see. | 16:18.35 |
| Robin_Watts | (I think) | 16:18.48 |
| | Actually, all that might be rubbish. | 16:25.02 |
| | I think the problem may be in the planar rop operations. | 16:25.16 |
| chrisl | kens: do you want me to bring Absolution Gap (finale of the Revelation Space series)? | 16:29.45 |
| kens | Oh, yes please! | 16:31.57 |
| | I'm brining back Redemption ark, and also terminal world (haven't read it yet, new book) | 16:32.21 |
| chrisl | I've just finished Terminal World - but that means I can reread Redemption Ark on the plane. | 16:32.53 |
| kens | Unless you'd like to try Rule 34 ? | 16:33.07 |
| mvrhel2 | are you guys flying out today? | 16:33.40 |
| kens | Tomorrow, but I thought it was Friday till chrisl corrected me | 16:33.52 |
| kens | is now dashing about madly packing and updating laptop | 16:34.11 |
| mvrhel2 | oh that would not have been good | 16:34.15 |
| chrisl | kens: not this time, thanks - if you're returning Redemption Ark I don't want *too* heavy a case! | 16:34.39 |
| | And I don't think I corrected you on the flight, must have been Robin_Watts | 16:35.09 |
| kens | :-) | 16:35.09 |
| | No, it was you mentionming packing | 16:35.20 |
| chrisl | Oh, right. Well, Absolution Gap is in the case, now - only clothes and things to worry about, now | 16:36.22 |
| kens | As long as the important things are done :-) | 16:36.37 |
| Robin_Watts | I am going to pack now, and look at the rop stuff later. | 16:36.56 |
| | packing will take finite time :) | 16:37.01 |
| henrys | sounds good. | 16:39.23 |
| | are you guys spending any extra time in chicago? | 16:39.46 |
| chrisl | henrys: not really any extra - same as last year, I think | 16:42.38 |
| kens | We'll be there on Sunday | 16:43.14 |
| | Most of the day | 16:43.19 |
| | Great 4 Windows updates failed on m,y laptop, now I get to try them again | 16:45.37 |
| chrisl | kens: my Vista64 VM has had four failing updates for a few months now - .Net is one of them. I tried the various solutions on the net, none worked for me. So decided not to care. | 16:46.49 |
| | going to finish packing, and run some errands now....... | 16:48.19 |
| kens | OK I too am heading off to finish packing, see you all in Chicago! | 17:02.38 |
| Robin_Watts | henrys: Can you point me at a PCL file that contains a single portrait monochrome image in it please? | 17:53.55 |
| mvrhel2 | bbiaw | 18:26.01 |
| echinos | Trying to convert from pdf to jpeg - get an error when using the density option. I've ssen forum posts saying it has something to do with lack of /tmp space and/or memory, is that likely? | 18:31.10 |
| Robin_Watts | density option? | 18:31.32 |
| | Can you give us a command line pleae ? | 18:31.38 |
| echinos | well, -r in gs | 18:31.46 |
| Robin_Watts | If it works at lower resolutions, and it fails as you increase, then yes, lack of memory is a possibility. But a command line would help us help you more. | 18:33.37 |
| echinos | well, it seems like it's only when I run it thro imagemagick that I get the ghostscript error | 18:34.11 |
| | if I just do the following it seems OK | 18:34.22 |
| | ghostscript -q -dBATCH -dNOPAUSE -sDEVICE=jpeg -r600x600 -â | 18:34.30 |
| | sOutputFile=test%d.jpg | 18:34.34 |
| | maybe that's the way to go then | 18:34.55 |
| Robin_Watts | gs -sDEVICE=jpeg -o test%d.jpg -r600 - | 18:35.31 |
| | less typing :) | 18:35.36 |
| echinos | cool | 18:35.55 |
| | bbiab | 18:35.59 |
| tor8 | Robin_Watts: I'm (finally) setting up an android build system on my mac | 18:36.01 |
| Robin_Watts | tor8: Ah, let me know how you get on with that. | 18:36.34 |
| tor8 | is there anything specific that requires 2.2 or will the code work on 2.1 (or ever 1.6)? | 18:36.38 |
| | just wondering about the target=android-8 line | 18:36.50 |
| | ran into a snag with jbig2dec's os_types.h ifdef cruft | 18:37.08 |
| | but other than that it's been smooth sailing | 18:37.14 |
| Robin_Watts | ISTR there was something that made it require more than android=3 | 18:37.16 |
| | yes, I thought I'd mentioned that before? | 18:37.24 |
| tor8 | you probably have, but I tend to forget :) | 18:37.49 |
| Robin_Watts | but I only have android-8 devices, hence that's all I've tested on. | 18:38.15 |
| tor8 | I should probably spend some time on jbig2dec, make sure it doesn't bit rot too much | 18:38.16 |
| | I have an android 2.3.3 phone and a 3.1 tablet | 18:39.02 |
| | Robin_Watts: "ant release" complains about not signing the apk | 18:42.00 |
| henrys | Robin_Watts sent you an email - sorry I was away from my desk. | 18:44.35 |
| Robin_Watts | thanks. | 18:45.05 |
| chrisl_away | tor8: Shailesh expressed some interest in messing with jbig2dec (as it seemed to be an area of not much activity), so we could possibly push some stuff his way. | 18:47.53 |
| echinos | Robin_Watts: Too big! What's resize in gs? | 18:48.48 |
| | ah, -g | 18:50.37 |
| henrys | bbiab | 18:56.21 |
| echinos | if you resize with -g600 will it keep the same aspect ratio for the height? | 19:03.34 |
| | ie. an you only specify resize one direction (lazy?) | 19:03.54 |
| tor8 | Robin_Watts: well, compiling for android-7 failed early: "android/bitmap.h: No such file or directory" :) | 19:05.20 |
| echinos | nope. is there a way to resize while keeping aspect ratio? | 19:15.13 |
| tor8 | echinos: try -r200 or something smaller than 600 dpi :) | 19:16.26 |
| echinos | I need higher res, there's detail on the page that's lost below 300 | 19:17.03 |
| Robin_Watts | Eh? | 19:17.30 |
| tor8 | so... what exactly is it you want? | 19:17.37 |
| echinos | convert PDF to jpg, dpi 300 or more (not sure yet, need to test different files) | 19:18.13 |
| | and the width/height have to be a reasonable size, but same aspect ratio as the PDF | 19:18.38 |
| tor8 | well, at 300 dpi they are going to be big | 19:18.49 |
| echinos | It's just what I'm trying in order to sharpen them up, if I make it higher DPI and then shrink, it looks better than a straight conversion | 19:19.38 |
| tor8 | you do realize that dpi is directly related to the size, I hope | 19:19.53 |
| Robin_Watts | echinos: right, but gs doesn't do that for you. | 19:19.54 |
| tor8 | if you want a better looking result, you can render at a high res then use another tool to resample the image, and get better anti-aliasing than gs will do | 19:20.22 |
| | imagemagick or pnmscale can do that | 19:20.36 |
| Robin_Watts | You need to let gs convert at a high dpi and then scale down in another tool. | 19:20.47 |
| echinos | so I can just run it thru im afterwards... I'll give it a shot | 19:21.18 |
| | I would do it all in im, but it's crashing due to a memory or /tmp space issue or something | 19:21.45 |
| tor8 | echinos: if you just want better anti-aliased text rendering, you can give pdfdraw from mupdf a swing too | 19:22.49 |
| echinos | on cmdline with no X? | 19:23.05 |
| tor8 | yes. | 19:23.12 |
| echinos | sweet | 19:23.15 |
| tor8 | pdfdraw outputs ppm or png directly | 19:23.44 |
| echinos | and then im, I spose | 19:24.00 |
| Robin_Watts | echinos: If there is text in the page, then the question arises "Why the hell are you using JPEG as an output format?" | 19:26.28 |
| | echinos: No, if you use mupdf you can probably just draw direct, and get a .png out that will be the required size/quality. | 19:27.08 |
| sebras | tor8: until oct 22nd I will still have an android 1.6 device in case you want to test. | 19:27.10 |
| | tor8: after that I believe I will have to return it. | 19:27.41 |
| tor8 | sebras: we can't even compile on 2.1 because of missing NDK api:s | 19:27.42 |
| | versions older than 2.2 don't have AndroidBitmap (from my quick research) | 19:28.17 |
| sebras | tor8: right. no point in keeping that old brick then. ;) | 19:28.49 |
| Robin_Watts | OK, testing patch now. | 19:30.53 |
| | committed. | 20:33.58 |
| | ../ghostpcl/tests_private\customer_tests\3656.bin is still wrong. | 22:26.27 |
| | Forward 1 day (to 2011/09/08)>>> | |
IRC Logs