| <<<Back 1 day (to 2013/07/24) | 2013/07/25 |
henrys | marcosw:were you going to get the customer #801 PCL thing going or should I? | 05:17.29 |
marcosw | henrys: it looked to me that rayjj had replied to all of custmer #801 | 06:27.31 |
| emails. which one are you referring to? | 06:27.54 |
chlebnik | Hi sorry for my english. I have problem with resolution for convert pdf -> jpg, default resolution is very low, how can i set my resolution for convert ? Thank you very much for help. | 07:49.17 |
kens | See the documentation, -r<number> sets the resolution | 07:49.39 |
chlebnik | In android | 07:51.08 |
| ? | 07:51.13 |
kens | SO you are not talking about Ghostscript then ? | 07:51.25 |
chlebnik | ups, i click to contact in mupdf page, and login here. | 07:52.29 |
| this is not help for android ? | 07:52.49 |
kens | THis is a channel for both MuPDF and Ghostscript, but its a good idea to say which one you are using | 07:53.00 |
| So what are you actually doing to convert your PDF to JPEG ? | 07:53.26 |
chlebnik | oh, sorry, MuPDF on Android Mobile | 07:53.47 |
kens | Yes, and what are you doing to convert teh file ? | 07:54.03 |
chlebnik | MuPDFCore myPdf = new MuPDFCore(pdfFileName); | 07:54.03 |
| myPdf.countPages(); | 07:54.11 |
| int pdf_w = (int) Math.round(myPdf.getPageSize(pageNumber - 1).x); int pdf_h = (int) Math.round(myPdf.getPageSize(pageNumber - 1).y); int x = (int) Math.round((zoom_l * pdf_w) / 210); int y = (int) Math.round((zoom_t * pdf_h) / 297); int w = (int) Math.round((zoom_w * pdf_w) / 210); int h = (int) Math.round((zoom_h * pdf_h) / 297); | 07:54.24 |
kens | OK so you are using the MuPDF library directly. You will have to wait until one of the MuPDF developers turns up, this is out of my scope. | 07:54.40 |
chlebnik | convert is here | 07:54.48 |
| Bitmap myImage = myPdf.drawPage(pageNumber - 1, pdf_w, pdf_h, x, y, w, h); | 07:54.49 |
kens | I expect one or more developers in the next hour or so, I'd suggest you hang on for a bit. THey will read the logs when they log on. | 07:55.33 |
chlebnik | ok, thank you very much, i wait here. Sorry im from czech republic, and my english is very bad, google translator is my teacher :) | 07:57.01 |
kens | Your English is just fine, don't worry! | 07:57.19 |
Robin_Watts | chlebnik: By default, pages are rendered at 72dpi. | 08:48.19 |
| If you want them rendered at a higher resolution, increase the width and height. | 08:48.47 |
sebras | Robin_Watts: do you mind taking a look at sebras/master? | 09:25.52 |
Robin_Watts | the last 2 ? | 09:27.11 |
sebras | Robin_Watts: y, there should only be two... | 09:27.42 |
| Robin_Watts: I'll start up my debian virtualbox to make sure that the built packages install correctly as well. | 09:28.37 |
Robin_Watts | ok, the debian thing seems plausible (but I am not qualified to say better than that) | 09:29.19 |
chlebnik | hi sorry my late | 09:30.00 |
| yes 72dpi | 09:30.07 |
Robin_Watts | The examples looks OK too. Though I might have been tempted by actual error checking if we don't supply a filename. | 09:30.19 |
sebras | Robin_Watts: right, I have been trying to convince tor* to take a look at them, but no response. ;) | 09:30.21 |
kens | tor has some other things on his mind right now.. :-( | 09:30.51 |
sebras | kens: I know. | 09:31.00 |
Robin_Watts | chlebnik: PDFs are constructed with the default coords being 72dpi. | 09:31.14 |
| To render at different resolutions, we pass in transforms to fz_run_page or fz_run_display_list that map from 72dpi to the required dpi. | 09:31.42 |
| The public API for MuPDF is at the C level. | 09:31.53 |
sebras | Robin_Watts: we used to crash horribly before so this patch improves matters. I have been trying to keep docs/example.c less than 100 lines so I'm hesitant to add more error checking. | 09:32.12 |
Robin_Watts | The java classes in the Android are NOT a public API. | 09:32.18 |
| sebras: Sure. | 09:32.21 |
| chlebnik: In order to do our android viewer, we have exposed just enough of the core libraries functionality over JNI so we can call what we want from java. | 09:33.10 |
| As such, if you attempt to reuse our java code, you should expect to encounter sharp edges. | 09:33.37 |
chlebnik | increase width and height... default is 210 and 297 | 09:38.13 |
| but page return anything about 1400 and 1900 | 09:38.38 |
sebras | Robin_Watts: d'oh found a mistake. | 09:38.39 |
Robin_Watts | chlebnik: For an A4 page width/height of 210/297 would be 1 pixel per mm. | 09:39.39 |
chlebnik | yes, page is 210/297, but if i use (myPdf.getPageSize(0).x return about 1400px | 09:40.38 |
Robin_Watts | chlebnik: Right. | 09:41.08 |
| This is what I mean about you needing to look at the C level. | 09:42.04 |
chlebnik | how i set this width to etc. 5000 | 09:42.23 |
| or use function fz_run_page is better ? | 09:43.41 |
Robin_Watts | chlebnik: The current java classes are designed to produce 'views' that can be displayed on the screen of an android device. | 09:43.47 |
| as such they are plumbed together to allow for panning/zooming etc. | 09:44.20 |
| IF you just want to get bitmaps out at a given size, then you will most likely find that the JNI interfaces exposed are not ideal. | 09:45.02 |
chlebnik | yes i known it, but i need transfer pdf and xps to jpg, and working with it. create there next text, next color border etc... | 09:45.04 |
Robin_Watts | So you might be best served to work at the C level, and put your own JNI interface on it. | 09:45.32 |
chlebnik | ufff my JNI it is very big programing for me | 09:46.35 |
| and if default is 72dpi, can I recompile mupdf clasess with new default resolution as 320 ? | 09:47.37 |
Robin_Watts | chlebnik: No. The 72dpi default is in the spec. | 09:47.57 |
| It's easy to do at the C level. | 09:48.05 |
tor7 | Robin_Watts: you mentioned something about a lua interface a week or two ago... anything come of that? | 09:49.13 |
Robin_Watts | someone is looking into it. | 09:49.30 |
| Luiz Henrique de Figueiredo | 09:49.50 |
chlebnik | sorry, what doing on C levet, new default dpi, or new width height, or new transfer ??? | 09:50.23 |
tor7 | creating wrappers for lua is one of the easiest languages to do so for, so it may make sense to make those as a prototype for the fleshed out JNI interface we've been discussing | 09:50.56 |
| brb, need to restart my chat client | 09:51.30 |
Robin_Watts | chlebnik: Driving mupdf to produce bitmaps at different scales is very simple to do at the C level. | 09:51.40 |
| But you will need to write interface code so the C can be called from java. | 09:52.19 |
| which means you will need to write JNI code. | 09:52.29 |
| If you're just passing in sizes and creating bitmaps, then it should be easy enough - all the code you need can be stolen from platform/android/jni/mupdf.c I think. | 09:53.11 |
chlebnik | on C level on Android device ? | 09:53.20 |
Robin_Watts | Yes. | 09:54.20 |
chlebnik | sorry, but im beginner in programing, c level, none, jni none, java beginer, i think use function page.setResolution, or setWidth.... or another... but programing in JNI Clevel, no, it not for me :( | 09:56.17 |
| It would turn out badly | 09:57.23 |
Robin_Watts | well, sorry, I can't magically produce such a call for you. | 09:58.26 |
kens | chrisl Robin_Watts I just got this warning from the build, I'm guessing its due to Robin's LCMS2 change: | 10:02.02 |
| New makefile issues: | 10:02.02 |
| gsicc_lcms2.$(OBJ): missing dependency on $(lcms2_extras_h) | 10:02.02 |
chrisl | I guess I'll let Robin deal with it, then..... :-) | 10:03.58 |
Robin_Watts | will fix, thanks. | 10:07.21 |
tor7 | Robin_Watts: the curl commit "Fix Release build" adds mixed line endings to the project file | 10:13.03 |
| or maybe I'm just reading "git diff" wrong | 10:13.58 |
Robin_Watts | tor7: I hope it shouldn't. I can't see why it should | 10:14.49 |
tor7 | looking at the checked out file it has all dos line-endings | 10:15.07 |
| but the git diff shows the new lines with a ^M at the end, but old lines without | 10:15.18 |
Robin_Watts | tor7: Which is correct for a project file. | 10:15.21 |
| I think that's just what git diff does. | 10:15.37 |
tor7 | probably | 10:15.41 |
| I believe we have our git setup to do normalized line-endings, so in the repo all line endings are unix-style but on checkout whatever your system prefers | 10:16.29 |
| but I guess since curl doesn't do that, I've never actually seen this sort of diff before | 10:17.12 |
| so it threw me | 10:17.24 |
| are there any more commits waiting to get urgently committed before the RC other than sebras? | 10:17.44 |
Robin_Watts | I'm working on fixing multipage svgs. | 10:22.25 |
| but that's not urgent for the rc. | 10:22.39 |
tor7 | right. so just the debian fixes sebras is working on then we can tag an rc and do the builds. | 10:23.07 |
sebras | tor7: hm.. update-alternatives seems to be easier than doing symlinks! | 10:25.57 |
| tor7: are you going to release 1.3 now..? | 10:31.06 |
| or 1.2? | 10:31.12 |
Robin_Watts | 1.3 this time. | 10:31.59 |
| 1.2 was the last one. | 10:32.03 |
sebras | missed one. | 10:32.09 |
Robin_Watts | lost count too, but 1.2 was tagged in Feb. | 10:32.29 |
| and the CHANGES file bit I just updated says "changes since 1.2" | 10:32.55 |
| http://doctoripsum.com/ | 10:33.05 |
chlebnik | Robin_Watts: there was write change default resolition, change w/h, use any function write in C or JNI, ok, more result, please could you write me the best way, for result this problem ? only theoretical, and i doing any test for programing it... very very please | 10:39.48 |
| what i must doing, programing and where togo to finish :) | 10:40.51 |
Robin_Watts | chlebnik: Sorry, I didn't understand that. | 10:41.27 |
chlebnik | very sorry for my english, i m from czech republik and my englist is very bad | 10:41.47 |
| i repeat it :) | 10:41.57 |
Robin_Watts | It is far better than my Czech :) | 10:42.03 |
chlebnik | :) thank you very much :) | 10:42.57 |
tor7 | Robin_Watts: does mutool poster work? | 10:43.04 |
| it seems to break on all but the first page | 10:43.42 |
Robin_Watts | chlebnik: Maybe you might want to look at: https://play.google.com/store/apps/details?id=com.newfrontiernomads.pdf&hl=en_GB | 10:43.51 |
| tor7: I haven't looked at it in ages. | 10:44.06 |
tor7 | or rather, mupdf breaks when changing pages. the first page always opens fine, but subsequent pages break. | 10:44.32 |
| error: object out of range (269504 0 R); xref size 40000 | 10:45.00 |
| warning: cannot load object (269504 0 R) into cache | 10:45.00 |
| etc | 10:45.02 |
| it's also an example of why we shouldn't write comments. | 10:45.22 |
Robin_Watts | tor7: I will look after I run. | 10:45.33 |
tor7 | the comments in pdfposter.c are still the same as the ones in pdfclean.c ... it's all a lie! | 10:45.47 |
Robin_Watts | yeah. | 10:46.19 |
chlebnik | I write my problem in global. My app every 30sec, get from specifi url big PDF or XPS, on specifi page (3), create cut from X1,Y1 to X2,Y2 and this save so JPG, to this JPG i add very string, color border, and another, but JPG is very bad quality, with small resolution. | 10:49.52 |
| I find your library | 10:50.04 |
| muPdf | 10:50.11 |
| compile very more files and very very day i install to eclipse to first run :) | 10:50.43 |
| bingo | 10:50.55 |
| now I creating app in java, and now i have problem with this resulution | 10:51.48 |
| in url what you send, it is new library extend your muPdf ? | 10:52.23 |
| but it show to view | 10:52.53 |
| but i need JPG file | 10:53.00 |
| JPG in FULL HD | 10:53.44 |
tor7 | paulgardiner, Robin_Watts: the incremental pdf_obj architecture we discussed earlier where we'd automatically move an object to the incremental section, is that stuff is all done? | 11:33.35 |
sebras | tor7: ok. I think my fixes for debian are done now. | 11:45.27 |
| tor7: I added a small script specific for debian to make the menu entry pop up a file selection dialog using zenity and then start mupdf on that particular file. | 11:46.01 |
| tor7: without it the menu entry does nothing (well it prints error messages to stderr, but you wouldn't seen them and there is no console) | 11:46.34 |
tor7 | sebras: sorry, pidgin crashed, I might've missed a message or two there | 11:47.17 |
sebras | tor7: ok. I think my fixes for debian are done now. | 11:47.42 |
| tor7: I added a small script specific for debian to make the menu entry pop up a file selection dialog using zenity and then start mupdf on that particular file. | 11:47.49 |
| tor7: without it the menu entry does nothing (well it prints error messages to stderr, but you wouldn't seen them and there is no console) | 11:47.55 |
tor7 | ah, that sounds great! | 11:48.03 |
sebras | tor7: read through the manpage update and correct my English! ;) | 11:48.26 |
| tor7: hm... | 11:49.02 |
tor7 | sebras: I used lib*.a in the example.c files so we don't have to remember to update them :) | 11:49.07 |
| maybe we should build them as part of "make" | 11:49.17 |
sebras | tor7: there is a problem with lib*.a | 11:49.27 |
tor7 | yeah, the -js- stuff... | 11:49.37 |
sebras | tor7: they get added on the command line in alphabetic order which causes linking errors because of the dependencies. | 11:49.54 |
tor7 | sebras: mupdf.1 "the previous page page" | 11:51.13 |
| if Shift is pressed <strikeout>on the other hand</strikeout> | 11:51.52 |
| what if I press Shift on the original hand? | 11:52.06 |
| ;) | 11:52.08 |
sebras | tor7: I can fix that, but that's not what I updated. | 11:52.39 |
| tor7: btw, how do I unpack a .xps and open mupdf on the directory? | 11:52.57 |
| tor7: what file should I be looking for? | 11:53.04 |
tor7 | unzip foo.xps && mupdf foo/_rels/.rels | 11:53.20 |
| let me have a go at the manpage paragraph | 11:54.10 |
sebras | tor7: sure. | 11:54.19 |
| tor7: I think my main task is to write a bad draft that spurs you into action... ;) | 11:54.47 |
| tor7: I'm updating the zenity-script though. | 11:57.55 |
| tor7: I forgot to add an "All supported formats" file-type. | 11:58.47 |
| tor7: but now that is present. | 11:58.51 |
tor7 | scroll wheel behaviour, what does shift do that differs from non-shifted scroll wheel? | 11:59.34 |
sebras | tor7: unknown. | 11:59.45 |
tor7 | "if shift is pressed on the other hand the page is panned" | 12:00.01 |
| I don't have a scroll wheel on this computer, so I can't test! | 12:00.15 |
sebras | tor7: can't help you, I have no scroll-wheel in my apartment! | 12:00.32 |
tor7 | okay, I could test on my mac with the two-finger-swipe | 12:01.29 |
| shift + scroll wheel pans horizontally | 12:01.36 |
sebras | tor7: hm.. more more mime associations necessary. | 12:07.08 |
Robin_Watts | I believe so, but paulgardiner is the man to ask. | 12:09.59 |
| chlebnik: The app I pointed you to is a wrapper around mupdf. | 12:10.20 |
| It allows other apps to request bitmap renderings of pages from PDFs. | 12:10.34 |
| It may do what you want. | 12:10.39 |
tor7 | sebras: mupdf-wrapper.sh -> mupdf-select-file? (or another more appropriate name) | 12:15.20 |
sebras | tor7: sure. | 12:15.28 |
tor7 | or call the script mupdf and make that call mupdf-x11 ;) | 12:16.00 |
sebras | tor7: I'm not sure whether that is appropriate. | 12:16.37 |
tor7 | no, after reading the script it isn't | 12:16.51 |
sebras | tor7: pretty ugly, but appears to get the job done. | 12:17.07 |
| still experimenting with it. | 12:17.21 |
tor7 | it's what the win32 build does by itself | 12:17.22 |
sebras | gnome is missing some mime-type associations so mupdf doesn;t popup in the file manager as it ought to. | 12:17.47 |
tor7 | platform/debian/mupdf.mime is too short :) | 12:18.24 |
sebras | I kknow. | 12:18.41 |
tor7 | there's a list of mime-types in source/fitz/document.c | 12:19.00 |
sebras | oh. | 12:20.23 |
tor7 | application/x-cbz | 12:21.10 |
| application/vnd.ms-xpsdocument | 12:21.15 |
sebras | I know. | 12:21.18 |
| what is .jfif-tbnl though..? | 12:22.17 |
tor7 | ask Robin_Watts | 12:22.27 |
| sebras: commits on tor/master | 12:25.02 |
sebras | tor7: why are we working on the same files? | 12:27.28 |
chlebnik | i look for the sended app url at home, and test it. Thak you very much, if I have a problem I'll call | 12:29.07 |
sebras | tor7: agh! stupid conflicts. :-( I have to run. I'll be back tonight. don't you dare do the rc until I'm done! ;) | 12:31.52 |
tor7 | sebras: I said I was going to have a stab at mupdf.1 | 12:33.44 |
| Robin_Watts: three commits on tor/master | 12:42.24 |
| Robin_Watts: and a (not to be merged) commit on tor/roadmap with a list of things that we should keep an eye on for the next release. | 12:46.32 |
| paulgardiner: ^ | 12:46.44 |
paulgardiner | hi tor7 | 12:46.57 |
| Ah right. Will look | 12:47.22 |
tor7 | I asked about the incremental pdf_obj stuff we discussed a while ago too, I think you may have missed the question :) | 12:47.40 |
| paulgardiner: anything to be added to or changed on the ROADMAP, please let me know | 12:48.11 |
paulgardiner | tor7: I think it's done. I imagine a few bugs will turn up, but other than that it seems to be working okay | 12:49.35 |
tor7 | paulgardiner: fab! it just fell off my map. | 12:49.54 |
paulgardiner | whether I'll ever manage to create an appearance stream with text in it via the pdf device is quite another thing. :-) | 12:53.09 |
| tor7: two commits are fine | 12:55.32 |
| Is the commented-out code intentional in the third? | 12:58.06 |
tor7 | I don't know if robin wants to use them in the future. it could be done better if not. | 12:58.42 |
paulgardiner | Ah right. One for Robin then | 12:59.09 |
Robin_Watts | looks | 13:01.52 |
paulgardiner | On the ROADMAP, both forms support and javascript DOM we may want to make more complete. | 13:02.29 |
Robin_Watts | I doubt we will use those values, but I like the idea of having them there commented out as documentation if you will. | 13:02.49 |
tor7 | paulgardiner: yeah. forms for other viewers should be on there somewhere as well. | 13:03.08 |
| and js support for non-androids. | 13:03.15 |
suprath | is there any help for C# | 13:03.41 |
| I want to render pdf file in C# controls | 13:03.59 |
| how to do? | 13:04.03 |
Robin_Watts | suprath: medically? | 13:04.04 |
tor7 | an idea I've been thinking about is replacing the existing x11 and win32 viewers with some common code that uses glut and opengl to draw the pages. should be faster, and have fewer platform specific bits. | 13:04.08 |
suprath | any idea? | 13:04.09 |
Robin_Watts | suprath: We don't do C# ourselves. | 13:04.42 |
| but mvrhel has just ported mupdf to Windows 8. | 13:04.56 |
paulgardiner | tor7: In an fz_text object, what coordinate space are the item's x and y? In particular, how are they affected by the font size? | 13:04.57 |
suprath | ok thanks | 13:05.02 |
| One doubt... | 13:05.15 |
Robin_Watts | as part of that he has a DLL that can be called via COM from different languages such as C#. | 13:05.28 |
| so that might be most of the job done. | 13:05.34 |
suprath | Which function actually gets the current pdf page | 13:05.35 |
tor7 | paulgardiner: the x/y are supposed to be combined with the fz_text->trm matrix as the e/f values | 13:05.41 |
Robin_Watts | suprath: "current" pdf page? | 13:05.48 |
suprath | yes | 13:05.53 |
Robin_Watts | There is no concept of "current" page. | 13:06.00 |
| at least in the lib. | 13:06.11 |
suprath | I mean render as matrics | 13:06.12 |
Robin_Watts | suprath: Look at doc/example.c | 13:06.30 |
suprath | I have seen help docs to save as bitmap sources | 13:06.36 |
paulgardiner | tor7: ta | 13:06.41 |
suprath | ok | 13:06.46 |
Robin_Watts | That's less than 100 lines that shows how to open a pdf and draw a page. | 13:06.47 |
tor7 | paulgardiner: each glyph is rendered using the text->trm with the e and f values substituted from the textitem->x and y | 13:07.31 |
Robin_Watts | tor7: In the roadmap; I think svgout is a high priority goal. | 13:08.44 |
| And there is no mention in there of lcms. | 13:09.25 |
| or rather no mention of a color managed solution. | 13:09.37 |
| As much as I like lcms, it has some pretty major inbuilt brokennesses. | 13:09.58 |
suprath | Hello Robin, thank you for your support... I have one more doubt... In this example also..its shown to save as an image file...but if I want to edit that pdf file or highlight it...it should not be saved as an image right | 13:10.00 |
| pls help | 13:10.02 |
tor7 | Robin_Watts: right. will fix. | 13:10.09 |
| Robin_Watts: if not lcms2, are there any other suitable options? | 13:10.22 |
Robin_Watts | That example gets a pixmap, and chooses to save it. | 13:10.23 |
| You just don't save it. | 13:10.26 |
| tor7: lcms3! | 13:10.32 |
paulgardiner | Just realised I don't know how are matrixes work. Is it (2x2mat(a,b,c,d) apply_to (x,y)) + (e,f) or 2x2mat(a,b,c,d) apply_t ((x,y) + (e,f)) ? | 13:10.37 |
Robin_Watts | I just have to talk Marti into it :) | 13:10.38 |
tor7 | :) | 13:10.39 |
Robin_Watts | paulgardiner: our matrices are: | 13:11.06 |
| a b 0 | 13:11.10 |
| c d 0 | 13:11.13 |
| e f 1 | 13:11.16 |
| Then normal 3x3 matrix rules apply. | 13:11.25 |
tor7 | paulgardiner: it's a 3x3 matrix with: ... what robin said | 13:11.28 |
| points are (x y 1) and vectors are (x y 0) | 13:11.47 |
paulgardiner | Ah of course. Applied to (x,y, 1) | 13:11.47 |
suprath_ | Robin | 13:14.01 |
| can u pls help me out of this issue | 13:14.09 |
| my connection lost meanwhile sorry for that | 13:14.25 |
Robin_Watts | suprath_: The example shows how to draw a bitmap then save it. | 13:14.50 |
tor7 | Robin_Watts: paulgardiner: updated tor/roadmap | 13:15.15 |
paulgardiner | So we multiply with the point on the left and the mat on the right (if using usual conventions) | 13:15.17 |
Robin_Watts | You want to use it, rather than save it, right? | 13:15.24 |
| paulgardiner: Yes. | 13:15.29 |
suprath_ | yes exactly... but my question is in other pdf viewers, are they saving it just like as image? | 13:15.36 |
Robin_Watts | suprath_: Viewers will use the image directly, I'd imagine. | 13:15.59 |
| but that's down to the app writer. | 13:16.17 |
| The job of the library is to render a bitmap. | 13:16.25 |
| how that is then presented to the user is the job of the app writer. | 13:16.37 |
suprath_ | ok so you have any idea to do so... to use the app writer? | 13:17.13 |
Robin_Watts | suprath_: To do what? | 13:17.24 |
suprath_ | any help would be much appreciated | 13:17.24 |
| I mean i want to highlight some text in a pdf then save it as pdf | 13:17.47 |
tor7 | paulgardiner: gl_Position = vec4(vec3(a_position, 1.0) * ctm, 1.0); so yes, point on left, matrix on right | 13:18.06 |
Robin_Watts | Ah, well, in that case you need to look at PDF annotations, I suspect. | 13:18.17 |
| We support various PDF annotation types, one of which is 'highlight'. | 13:18.46 |
suprath_ | yes... I also believe that... only if the pdf is rendered as annotation only then we can edit it | 13:19.07 |
tor7 | paulgardiner: which is the opposite of opengl conventions... | 13:19.22 |
paulgardiner | tor7: So I think that implies that I should set the x/y in text items to be in "page space" irrespective of the font size | 13:19.22 |
Robin_Watts | No, you can add annotations to existing PDFs. So any text can be highlighted. | 13:19.34 |
tor7 | paulgardiner: yes, the x/y are not affected by the trm scaling and rotation | 13:19.45 |
Robin_Watts | There is code in platform/android/jni/mupdf.c that calls it. | 13:19.58 |
suprath_ | ok Robin... but in that can should I save that pdf as image? or in which format we have to show/render it | 13:20.24 |
paulgardiner | tor7: something is multiplying them by the font size. I was just checking that that is wrong before going off to fix it. | 13:20.24 |
tor7 | so they're effectively the position in the page space as you call it (the "ctm" at the point of drawing the text object) | 13:20.27 |
Robin_Watts | suprath_: You call fz_open_document to open a document. | 13:20.55 |
| That returns a handle. | 13:21.04 |
| Using that handle you can then call fz_load_page to get pages from the document. | 13:21.13 |
| You can then render those pages to a bitmap for display. | 13:21.26 |
| Or you can fiddle with the annotations on those pages. | 13:21.34 |
| When you are finished, you can save the document back using the original handle. | 13:21.46 |
| So you end up with a modified PDF at the end. | 13:21.56 |
paulgardiner | tor7: I know "page space" is the wrong term. What's the correct one? :-) | 13:22.15 |
tor7 | I have no idea :) | 13:22.24 |
suprath_ | oh great.... so if we give any annotations to that orginal file will be saved along with the loaded file right..... ohh great idea | 13:22.49 |
Robin_Watts | paulgardiner: "document space" = the default 72dpi space as given by the mediabox etc. | 13:23.08 |
| "device space" = the actual set of pixels we render too. | 13:23.20 |
paulgardiner | tor7: :-) I feel better about not knowing | 13:23.24 |
| Robin_Watts: Bah. You ruined it. Feel bad again now | 13:23.42 |
Robin_Watts | I can remember "device space" easily enough. | 13:24.08 |
| "document space" is therefore "the other one" :) | 13:24.15 |
suprath_ | can u point out an example for doing annotation...pls | 13:24.59 |
| i mean link of code | 13:25.09 |
Robin_Watts | suprath_: I said. Look in platform/android/jni/mupdf. | 13:25.19 |
| suprath_: I said. Look in platform/android/jni/mupdf.c | 13:25.21 |
suprath_ | ok | 13:25.27 |
| I think in that code there is nothing specifying how to do annotations... | 13:28.24 |
| sorry if I am mislead | 13:28.38 |
| there is e_openFile | 13:29.08 |
| gotoPageInternal( | 13:29.23 |
scarpino | hi all, is this channel also about ghostpdl? | 13:29.45 |
kens | scarpino, yes all Artifex products | 13:30.04 |
suprath_ | Robin, have you ever come across such other examples | 13:30.08 |
scarpino | thanks. | 13:30.10 |
suprath_ | if so could you pls share with me | 13:30.17 |
scarpino | I'm trying to get info about the conversion from an SPL file (PCL raw data) to a PDF | 13:30.40 |
suprath_ | Hello Kens can you help me out | 13:30.51 |
Robin_Watts | suprath_: No, the only example of code we have that drives the library to handle annotations is within the android app, and hence in that file. | 13:30.56 |
kens | suprath, no, I know little about MuPDF | 13:31.02 |
scarpino | how to get debug/errors messages during using the pcl6 script? | 13:31.05 |
| during/d | 13:31.15 |
kens | scarpino I'm not sure what you mean | 13:31.20 |
scarpino | ok, trying to rephrase that | 13:31.28 |
kens | There is no 'script', just PCL input, and the ghostpdl executable | 13:31.36 |
| Unless you specifically turn off debug and error messages, they will be emitted on stdout and stderr | 13:31.57 |
scarpino | I see, so I guess I only have to rebuild ghostpdl with debug symbols? | 13:32.16 |
Robin_Watts | scarpino: Presumably you are using something like: pcl6 -sDEVICE=pdfwrite -o out.pdf in.pcl | 13:32.20 |
scarpino | Robin_Watts: exactly | 13:32.28 |
kens | scarpino, no, ghostpdl will emit its own messages, regardless of compiler debugging information | 13:32.43 |
scarpino | pcl6 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=test.pdf file.SPL more precisly | 13:33.01 |
kens | scarpino, perhaps if you exoplained your actual problem ? | 13:33.06 |
Robin_Watts | scarpino: Right. As kens says, you will get any debug or error message on stdout/stderr. | 13:33.08 |
| It's possible that if you're feeding a well formed file in, you won't see any such messages though, as pcl6 may have nothing to report :) | 13:33.36 |
suprath_ | Robin thanks for your kind support | 13:33.47 |
| have a nice day | 13:33.53 |
| bye | 13:33.54 |
Robin_Watts | What messages were you hoping to see? | 13:33.54 |
| suprath_: You're welcome. Good luck. | 13:34.03 |
scarpino | kens: I used successufully the pcl2pdf script to convert PCL files to PDF, but I 1 pdf has some weird page | 13:34.14 |
| Robin_Watts: too^ | 13:34.20 |
kens | scarpino, I'd need to see an example to be sure, but.... | 13:34.30 |
scarpino | I can send you the file via mail if you want | 13:34.43 |
kens | The PCL graphics model does not map precisly to the PDF graphics model | 13:34.44 |
scarpino | both SPL and the pdf one | 13:34.49 |
kens | Some things we don't even atgtempt to convert (PCL rasterops for example) | 13:34.59 |
| scarpino you cna send me the file if you like, but I'm not a PCL expert I'm afraid :-) | 13:35.15 |
scarpino | :-) | 13:35.21 |
kens | THough I do maintain pdfwrite, so it would come to me eventually anyway | 13:35.38 |
scarpino | this is the PDF I get http://wstaw.org/m/2013/07/25/plasma-desktopzRz512.png | 13:35.57 |
kens | as long as its a sensible size you can send it to ken.sharp at artifex.com, let me look at the PDF.. | 13:36.07 |
scarpino | the others page are fine, just that one is weird | 13:36.08 |
| I guess because of the font used for the table maybe | 13:36.24 |
kens | Err, its hard for me to know what's weird :-) | 13:36.29 |
| Not knowing what its supposed to look like | 13:36.42 |
Robin_Watts | scarpino: The PDF is the least interesting thing you can give us. The PCL is much more useful, as from that we can generate the PDF. | 13:36.43 |
scarpino | Robin_Watts: ok, you mean the SPL input file right? | 13:37.01 |
kens | Yes, the PCL file (.spl is Microsoft for 'spool' and referes to any of a numebr of Page description languages) | 13:37.28 |
scarpino | Robin_Watts: if you want to share with me your mail address I can send you the file | 13:37.29 |
Robin_Watts | scarpino: kens is your man here. | 13:37.57 |
kens | My mail address is above, Robin's is the same format except robin.watts instead of ken.sharp | 13:37.58 |
scarpino | oh saw it | 13:38.23 |
kens | very slightly obfuscated :-) Just to avoid scrapers | 13:38.46 |
scarpino | ;-) | 13:38.57 |
| sent. is 3.8MB | 13:39.54 |
kens | Might take a few minutes to ge here at that size | 13:40.09 |
scarpino | page 3 is the "weird one" | 13:40.16 |
kens | trickling in now | 13:40.21 |
kens | quickly rebuilds PCL | 13:41.00 |
scarpino | I'm using pcl 9.07 | 13:41.20 |
| stable | 13:41.27 |
kens | Nice to see someone using current software :-) | 13:41.33 |
scarpino | is an arch linux developer, only current software here! | 13:42.00 |
kens | scarpino : the file looks 'wrong' when rendered to screen, so pdfwrite won't get it any more correct | 13:42.46 |
Robin_Watts | scarpino: This means that either the input PCL is broken, or we have a bug in our PCL interpreter code. | 13:43.32 |
| It sounds like you need to speak to henrys when he arrives. | 13:43.46 |
kens | yeah, I was just comparing gthe PDF foutput, which is the same as the rendered screen version | 13:43.51 |
| I have no idea what would cause that, I don't speak PCL well enough | 13:44.16 |
| My suggestion would be to open a bug report for it unless you want to wait a couple of hours and discuss it with henrys first | 13:44.44 |
scarpino | I can wait. (please do not public that file) | 13:45.10 |
kens | No problem, I'll delete it | 13:45.23 |
scarpino | you can take it, just do not attach it in a bug report | 13:45.34 |
| no problem if you are able to cut the weird part | 13:45.51 |
Robin_Watts | scarpino: If you create a bug on bugs.ghostscript.com, we can attach the bug as a 'private' attachment so no one outside our company can see it. | 13:45.53 |
kens | If it can't be made public, the don't open a bug report unelss someone is available to immeidatley mark the attachment private | 13:45.56 |
scarpino | Robin_Watts: that is fine | 13:46.02 |
kens | Easiest woudl be to wait for henrys to come online and see what he makes of it I expect, if you don't mind waiting (he's in Coorado) | 13:46.44 |
| Ooops Colorado* | 13:46.55 |
scarpino | Anyway, to explain you the situation (but I guess you already got it): that file is generated by a software and sent to physical printer. Actually I replaced the physical printer with a digital one. | 13:47.07 |
kens | Seems reasonable | 13:47.17 |
scarpino | so, I guess the SPL is correctly generated | 13:47.28 |
kens | WOw, page 6 onwards go badly wrong | 13:47.36 |
scarpino | let me check | 13:47.43 |
kens | It looks like the PCL is begin emitted as text | 13:47.46 |
| page 14 for example | 13:48.07 |
| Are all the pages meant ot look like page 1 ? | 13:48.55 |
| It looks like it a bunch of forms maybe ? | 13:49.04 |
scarpino | wait | 13:49.41 |
kens | Italian isn't really up to translating these | 13:49.49 |
scarpino | I can send you another PDF correctly rendered (scan for real paper) which has some part in common with that one so you see how it should appears | 13:52.47 |
kens | What I see is: | 13:52.47 |
| Page 1 is a neatly filled in form | 13:52.47 |
| Page 2 is some kind of bioler plate legalese | 13:52.47 |
| Page 3 looks like it ought to be likepage 1, but is corrupted | 13:52.47 |
| Page 4 looks like the text that should be in the form fields on page 3 | 13:52.47 |
| Page 5 is the boierplate legalese like on page 2 | 13:52.48 |
| Page 6 is like page 3 | 13:52.48 |
| and so on | 13:52.49 |
| scarpino : not really any point in sending it to me, and I exepct henrys has his ownways of seeing what it 'ought' to look like | 13:54.00 |
scarpino | ok | 13:54.22 |
kens | Until the PCL interpreter renders it correctly, its pretty unlikely that pdfwrite will make a sensible PDF from it | 13:54.24 |
scarpino | how do I "invoke" the pcl interpreter? | 13:54.45 |
kens | notices henrys is online and wonders if he is just hiding :-) | 13:54.49 |
| scarpino the executable is called pcl6.exe on WIndows, I would guess its pcl6 on Linux | 13:55.07 |
scarpino | oh maybe then I just need to exec pcl6 without any params | 13:55.26 |
kens | The Windows one renders to the screen unless you tell it otherwise, I think the Linux one defaults to X11 | 13:55.32 |
| I'll just kick of a VM and look | 13:55.57 |
scarpino | failed | 13:56.49 |
kens | OK ./pcl6 in the ghostpdl/gs/obj folder starts it up, just a minute | 13:58.32 |
scarpino | uhm maybe I built it without x11 support, on the net I found I have to use -sDEVICE=x11 | 13:59.48 |
| but there's no such option in my installation | 13:59.56 |
scarpino | rebuilds | 13:59.58 |
kens | Possibly, I don't use it on Linux mostly | 14:00.06 |
| Hmm, mine doesn't list X11 support in the devices | 14:00.35 |
kens | wonders if we should fix that | 14:01.04 |
| You oculd always write the output to a TIFF file or a PNG | 14:01.58 |
| ./pcl6 -sDEVICE=png16m -o out%d.png 00105.spl | 14:03.26 |
| For some reason that seems to run really slowly on my Fedora VM, but it does work | 14:05.59 |
Robin_Watts | tor7: So, it seems that SVG 1.2 is basicallu unsupported in everything, so I can't make multipage SVG files using that. | 14:12.25 |
scarpino | ok works here with sDEVICE=x11 | 14:12.28 |
Robin_Watts | 1.1 doesn't support multipage at all. | 14:12.31 |
tor7 | Robin_Watts: right. | 14:12.41 |
kens | scarpino, fair enough, my build must be out of date or something | 14:12.48 |
Robin_Watts | and now they are officially burying 1.2, and going straight to 2.0 by this time next year. | 14:12.55 |
tor7 | Robin_Watts: does 2.0 have multi-page support? | 14:13.07 |
Robin_Watts | looking now. | 14:13.13 |
| It seems not. | 14:15.04 |
| so I'm going to close the bug asking for multi-page support. | 14:19.18 |
chrisl | kens, scarpino: my Linux pcl6 build has the x11 and x11alpha devices in it | 14:20.45 |
scarpino | chrisl: yes, mine too now | 14:20.58 |
| some header was missing ;-) | 14:21.05 |
chrisl | Ah, cool | 14:21.13 |
scarpino | thanks anyway | 14:21.18 |
chrisl | scarpino: I just couldn't remember if the configure script for PCL controlled the inclusion of the x11 devices | 14:22.36 |
kens | I may not have somethign configure wants for X11 support, I'm not going to worry about it :-) | 14:23.08 |
chrisl | kens: yeh, you'll need the x11 dev packages installed | 14:23.34 |
kens | I guess I don't. like I said, not going to worry | 14:24.13 |
henrys | scarpino: what is the issue? | 14:39.59 |
kens | henrys, badly rendered pages, looks like some PCL is rendered as text | 14:40.27 |
| I'll mail you the file if you like ? | 14:40.46 |
henrys | sure why no bug? | 14:41.04 |
kens | Mostly because he wants the file to be prviatge, and by then we had gone a long way into it | 14:41.23 |
scarpino | exactly. | 14:41.38 |
| but I agree that the file is kept in your company only - not public then | 14:41.56 |
henrys | scarpino: generally we don't do that but since we've started ... | 14:42.09 |
kens | henrys mail on its way | 14:42.12 |
scarpino | henrys: thanks. there're sensitive data | 14:43.08 |
kens | wow, slow to send :-( | 14:43.39 |
kens | should have zipped it | 14:43.54 |
| OK its gone from this end | 14:44.08 |
henrys | kens:got it. | 14:57.27 |
scarpino | henrys: I'm here if you need anything. thank you for looking into it | 15:11.35 |
henrys | scarpino: did you try it on an HP printer? | 15:12.09 |
scarpino | what that mean? if you mean if I did try to print to a physical printer yes I did | 15:12.33 |
| and the generated file is ok | 15:12.48 |
| s/generated/printed | 15:12.52 |
henrys | scarpion:looks like a legitimate bug I can create a bug report on bugzilla with a private attachment (only our staff will be able to see it) and get to it over the next few days. | 15:28.01 |
scarpino | henrys: it's fine! | 15:29.00 |
henrys | scarpino:http://bugs.ghostscript.com/show_bug.cgi?id=694434 | 15:39.59 |
scarpino | thank you | 15:41.47 |
Robin_Watts | tor7: SVG output device bug fix on robin/master | 15:45.59 |
paulgardiner | Robin_Watts, tor7: I seem to be able to break a PDF file just by adding a new font to its resources. Acrobat wont load it, although we can. mutool clean gives no errors, but the result still wont load into Acrobat. | 15:46.15 |
kens | What dopes GS say if you render it there ? | 15:46.34 |
paulgardiner | I've cleaned the file before and after adding the font. Here's the diff: http://pastebin.com/V1aiSyfB | 15:46.48 |
| gen of 65537 is suspicious, but doesn't seem to be the cause. | 15:47.15 |
Robin_Watts | paulgardiner: On every page of a PDF file in the resources dict there is a /ProcSet | 15:47.34 |
| which is an array. | 15:47.40 |
| What is that value ? | 15:47.56 |
| yeah, the gen number is odd, and should be fixed, but presumably you can edit that down and it's not the cause. | 15:48.58 |
paulgardiner | That's right | 15:49.09 |
Robin_Watts | For a page with fonts on you expect to see: /ProcSet [ /PDF /Text ] | 15:49.40 |
paulgardiner | ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ] | 15:49.41 |
Robin_Watts | ok, so that's fine. | 15:49.54 |
| Can you put the file up somewhere? | 15:50.02 |
paulgardiner | Sure | 15:50.10 |
| http://intranet.glidos.net/~paul/Christmas%20puzzle%202012%20-%20freetext.pdf | 15:51.02 |
| That's before running clean. I can stick a post-clean vs up too if that helps | 15:51.23 |
kens | GS is happy with it :-) | 15:52.10 |
| Acrobat says 'Expected a name object' | 15:52.30 |
paulgardiner | Ah! | 15:52.39 |
kens | WHen Acrobat gives you an error dialog, try pressing Control while clicking the OK, sometimes it gives more information | 15:53.42 |
paulgardiner | Ta. Useful | 15:53.57 |
Robin_Watts | handy tip! | 15:54.05 |
| Aha. /Subtype, innit | 15:54.31 |
| not /SubType | 15:54.34 |
kens | :) | 15:54.50 |
paulgardiner | OMG! | 15:55.02 |
kens | Works fine like that :-) | 15:55.26 |
paulgardiner | I'm banging my own head on the desk, so no need to come around and do it for me. | 15:55.51 |
kens | Acrobat does then offer to save changes so its not totally happy, but.... | 15:56.19 |
Robin_Watts | paulgardiner: Did you return that USB memory card reader to me? I think you did... | 15:56.21 |
paulgardiner | Robin_Watts: No. Still have it here. | 15:56.45 |
Robin_Watts | Ah. I shall stop looking for it then :) | 15:57.36 |
kens | OK I'm off to pack, will be back online next Wednesday. Enjoy your holiday Robin_Watts, try not to find any dangerous wildlife :-) | 16:07.05 |
Robin_Watts | kens: Thanks. | 16:07.18 |
| too slow. | 16:07.20 |
dogisfat | Question about clip paths. | 16:16.16 |
| When I have a clipping path that clips an image ghostscript reports the path as invalid. However valid path resides in the path_list portion of the clip path structure. How do I know when an image has a valid clip path? If the path_list is not NULL? | 16:16.24 |
Robin_Watts | dogisfat: So, you have a gx_clip_path? | 16:17.41 |
| with it's path_valid member set to false? | 16:17.54 |
| s/it's/its/ | 16:18.04 |
dogisfat | Robin_Watts: Yes | 16:18.05 |
Robin_Watts | In that case you cannot assume anything about the contents of ->path. | 16:18.29 |
| You have to work with the rectangle list. | 16:18.46 |
dogisfat | but what of path_list | 16:18.52 |
| Robin_Watts: Do I need to check both path_list and rect_list? | 16:19.44 |
Robin_Watts | If gx_clip_path is non NULL, you have a "valid" clip path. | 16:20.00 |
| Some clippaths are described by a simple path - in those cases, path_valid is set. | 16:20.18 |
| Others (such as ones formed by the intersection of several paths) do NOT have a simple path representation. | 16:20.47 |
dogisfat | That makes sense. Now the next question. | 16:20.52 |
Robin_Watts | those are represented by a list of rectangles. | 16:20.55 |
dogisfat | So the paths residing within path_list have a winding fill rule. When I plot the clip path out by hand the entire resulting path is filled, this does not seem correct. | 16:21.01 |
Robin_Watts | That sounds correct to me. | 16:21.17 |
dogisfat | I essentially have a rotated box with two circles inside of it. The circles clip what is under the box. How do you know what region to clip? | 16:22.13 |
| In my case the winding rule suggests that the box and circles are filled. | 16:22.39 |
Robin_Watts | In this case, do is path_valid ? | 16:23.03 |
| In this case, is path_valid ? | 16:23.09 |
dogisfat | No, it is a complex path residing in path_list. | 16:23.24 |
Robin_Watts | if path_valid == 0 then you cannot expect to get any information from drawing out paths. | 16:24.05 |
| how many more ways would you like me to say that? :) | 16:24.20 |
dogisfat | I am obviously confused. I thought that having path_valid only applied to the path member within the gx_clip_path_s struct. | 16:25.20 |
| Since the gx_clip_path is not null you said I have a "valid" clip path, however the path_valid member is zero yet there are paths within the path_list member. I have been trying to replicate what is happening in the PDF writer device in regards to the clip paths. | 16:27.09 |
| the PDFWriter does not even seem to consider the path_valid member. | 16:27.37 |
Robin_Watts | I am unsure of the correct answer here. | 16:29.03 |
| I'd need to dig through the code. | 16:29.10 |
| I'm not sure what the path_list is all about. | 16:29.22 |
dogisfat | within the gx_path_list there is a path_list member which is a single linked list which contains a gx_path an rc_header and a fill rule designator | 16:30.22 |
Robin_Watts | dogisfat: OK, from a quick look at the code, it looks to me as if the path_list contains a list of all the paths that must be intersected together to give the actual clip region. | 16:33.11 |
| And that is valid regardless of path_valid. | 16:33.25 |
dogisfat | Robin_Watts: Right, on what basis are they intersected? Should it be a subtraction? | 16:34.05 |
Robin_Watts | dogisfat: Eh? They are intersected. | 16:34.25 |
| Draw one path and fill it in red, draw another path and fill it in blue. | 16:34.48 |
| The purple bits are the intersection. | 16:34.55 |
| I think. | 16:35.11 |
| I mean, I *think* the contents of path_list are intersected. I'd need to spend time that I don't have to look into it in more detail. | 16:35.39 |
dogisfat | Right, ok. I was thinking more in terms of the fill rules. That makes sense from what I am seeing. | 16:36.08 |
| How are intersections supposed to occur? Do you take the first path and then intersect that with the subsequent paths and join the resulting intersections? | 16:42.08 |
Robin_Watts | I don't follow the question. | 16:43.52 |
| In order for a point to be inside the clipping path (i.e. not clipped away) it needs to be inside ALL the paths in the clipping path list. | 16:44.24 |
| If it's not, it's discarded. | 16:44.34 |
dogisfat | That is not what is happening from what I can tell, but I would agree that is what I think should happen. | 16:45.12 |
| In this example: http://puu.sh/3Luf9.ps produces the following path: http://puu.sh/3Lull.xml (See the clip path) | 16:52.37 |
| Essentially there are no overlaps between all of the paths that mask the image. | 16:53.10 |
| Or at least that is was GS is telling me. | 16:53.27 |
Robin_Watts | dogisfat: Well, it's possible that it's the union. I'm sorry, but I really don't have time to look at this now. | 16:55.14 |
dogisfat | Thank you for your help, please let me know if I am ever a bother. | 16:55.43 |
Robin_Watts | no problem. I am off on holiday on saturday, and I'm trying to get stuff finished. | 16:56.09 |
dogisfat | Thanks again! | 16:57.28 |
Robin_Watts | tor7: ping | 17:59.21 |
| or paulgardiner even. | 17:59.36 |
| chrisl: OK, lcms 2.5 fiddling complete for the release. We have no bugfixes left outstanding, so we can safely run with the stock one. | 18:15.19 |
| We will be slower with the stock one though as we have optimised transforms in our version. | 18:15.39 |
| I have tried pulling them out as a standalone lcms plug in, but that reveals strange effects that I have mailed Marti about. | 18:16.09 |
| so for now, I've just rolled them in as they were before. | 18:16.21 |
| tor7: Another fix on robin/master | 18:23.28 |
tor7 | Robin_Watts: is_unicode_ws, couldn't that be done using the ucdn functions as well? (though I suspect it'll be slower performance due to the generality of the lookup tables) | 18:25.02 |
| Robin_Watts: poster fix looks good | 18:26.55 |
Robin_Watts | tor7: I use the same is_unicode_wspace function in the text extraction stuff. | 18:27.36 |
| I could just make it fz_is_unicode_wspace ? | 18:27.56 |
| but we hit it a lot when outputting text in svgs, so a generalised call to ucdn would need to be fast. | 18:28.31 |
tor7 | we could measure the performance of it, would be good to know how fast it is | 18:29.41 |
| we call ucdn once per glyph in the RTL pass already | 18:29.54 |
| ucdn_get_general_category() and if it is UCDN_GENERAL_CATEGORY_Z[LPS], should match all whitespace chars | 18:30.40 |
| ZS for space, ZL and ZP for line breaks | 18:30.55 |
Robin_Watts | tor7: Can i commit it as is, and we can put that on the todo list ? | 18:31.29 |
tor7 | sure thing | 18:31.36 |
Robin_Watts | It means I can mail raed back. thanks. | 18:31.41 |
tor7 | Robin_Watts: tab and LF and CR are in the CC category (control chars) | 18:32.29 |
Robin_Watts | tor7: right, but I'm sure the svg parsers whitespace eater will treat them as spaces. | 18:33.27 |
tor7 | Robin_Watts: yeah. | 18:33.45 |
| is_wspace should maybe be !isprint() equivalent? | 18:34.20 |
| Robin_Watts: from the XML spec: SÂ Â Â ::=Â Â Â (#x20 | #x9 | #xD | #xA)+ | 18:36.46 |
Robin_Watts | tor7: Anything else is treated as non whitespace? | 18:37.18 |
| is_xml_wspace then ? | 18:37.39 |
tor7 | from my reading, yes | 18:37.43 |
| http://www.w3.org/TR/REC-xml/#NT-S | 18:38.03 |
| and #xD is supposedly stripped (so only \n line endings in canonical xml) | 18:38.39 |
mvrhel_laptop | bbiaw.. making more progress on windows phone zoom updating is working. just need to get text search and hyperlinks in place | 18:48.28 |
Robin_Watts | tor7: fix on robin/master then. | 18:48.52 |
| If poster tries to use linearisation, it all goes potty. Missing objects that are annotations. I wonder why. | 18:49.34 |
| clean -l works though so I won't lose sleep over it. | 18:49.58 |
tor7 | Robin_Watts: add a bug for it, assigned to yourself, and then we can forget it in good conscience :) | 18:50.32 |
| Robin_Watts: fix looks good. | 18:50.36 |
| shall I rebase and push the three on tor/master as well? | 18:50.48 |
| or do you want to change the warning fix in pdf_load_hints? | 18:51.19 |
Robin_Watts | tor7: sorry, got called away. All fixes (yours and mine) pushed. | 23:09.30 |
| Forward 1 day (to 2013/07/26)>>> | |