| | <<<Back 1 day (to 2015/10/12) | 20151013 |
| kens | chrisl should Norbert even be trying to build ghostpdl ? I'm thinking not..... | 07:11.52 |
| chrisl | kens: Nope, it doesn't work in many, many other ways than that | 07:12.52 |
| kens | Then I'll close it as invalid and tell him to leave it alone | 07:13.05 |
| | FWIW with VS 2008 I get an argc of 10, and it still crashes. | 07:14.25 |
| chrisl | All the target is there to do is to give us a build with all the interpreters linked to the graphics library, and thus a starting point for a language switching implementation that actually works | 07:16.16 |
| | Perhaps I should remove it from master, and put it on a branch..... | 07:18.43 |
| kens | Well it went out in the last release, so probably a bit late. | 07:19.03 |
| chrisl | In the release, it is not built in the default target list - you have to specifically ask for it | 07:20.11 |
| kens | Presumably its still i the list of VS targets | 07:20.35 |
| | Its not so much that he's building it, as attempting to run it | 07:20.51 |
| chrisl | The ghostpdl project file is not in the release, and (obvously) it's not listed in the solution. So, again, it takes special effort to find and use the target. | 07:22.45 |
| kens | Its listed in my VS solution | 07:23.01 |
| | Unless you removed t from the release solution ? | 07:23.15 |
| chrisl | I did | 07:23.21 |
| kens | Well in that case he's being dumb | 07:23.30 |
| chrisl | He may, of course, be using the code in git | 07:25.40 |
| kens | He is, he says 'master' but that'snot really an excuse | 07:25.51 |
| chrisl | Well, by definition, that is in-development, and unstable | 07:26.25 |
| kens | I wa just writing that, but longer, I agree completely | 07:26.41 |
| | Well, not too surprsiginly I guess, gxps doesn't handle PJL at all. | 09:03.52 |
| chrisl | "Yet" | 09:04.09 |
| kens | Sure, but I got the impression from Henry that he thought it did | 09:04.28 |
| chrisl | I'm not even 100% sure the PJL code is linked into gxps | 09:05.27 |
| kens | If it is, it doesn't run it | 09:05.42 |
| chrisl | If it's not there, it's easy enough to add - just let me know | 09:06.04 |
| kens | I'm not bothered right now, the bug report is PCL->PDF/A :-) | 09:06.23 |
| | I'm perfectly happy to wait for XPS until the whiole refactoring/language switch is completed | 09:06.45 |
| | I can now produce PDF/A from (limited numbers of) PCL and PXL input files, so I'm going to move on to the slightly more complex area of distillerparams | 09:08.02 |
| Zephyr | Hi, im trying to use Ghostscript to convert several PDF's into jpg files. My problem is that on some files the process takes a few secounds while on a file of similar size it takes 1 hour+. I tried messing with Different combinations of of adding memory and am currently running with | 10:47.09 |
| | -dNumRenderingThreads=4 -dBandHeight=100 -dMaxPatternBitmap=20000000 -dMaxBitmap=1000000000 -dBandBufferSpace=500000000 -sBandListStorage=memory -dBufferSpace=1000000000 -c 300000000 setvmthreshold | 10:47.12 |
| | With the PDF that runs fast i can see that the rendering is spread across the different processors but with the slow ones it is not. Would you be able to hint a where my problem might be? Or can the complexity of the PDF simply vary this much on a similar page count and file size? | 10:47.20 |
| chrisl | Far too many possibilities to even guess | 10:47.43 |
| kens | Can't comment at all without seeing an example PDF file. THe most likely problem is that your PDF contains complex transparency. Almost certainly using -0dNumRenderingThreads=4 will make it slower. You haven't (apparently) specified a resoltion either | 10:48.15 |
| | PDF transparency *massively* complicates rendering | 10:49.08 |
| chrisl | FWIW, I would try -dNOTRANSPARENCY and -dNOINTERPOLATE - one of those might hint at the root cause | 10:49.32 |
| Zephyr | The full command includes gs -dBATCH -dNOPAUSE -dSAFER -sDEVICE=jpeg -dJPEG=75-dTextAlphaBits=4 -dGraphicsAlphaBits=2 -dAlignToPixels=1 -r75x75 -dUseCropBox | 10:50.36 |
| | but i will try with notransparency and interpolate and see if that does any difference. | 10:50.58 |
| kens | I don't thnk -dJPEG=75 does anythign at all. Don't use GraphicsAlphaBits and TextAlphaBits if you want performance | 10:51.11 |
| Zephyr | i had to add the textalphabits to get readable text on some of the pdfs i had to work with. unfortunately | 10:52.20 |
| kens | I find it hard to believe that at 75 dpi and using JPEG the text is readable at all | 10:52.42 |
| | JPEG is a really bad choice if you want quality in your output | 10:52.58 |
| chrisl | I've *never* found anti-aliasing to make text more legible - seems like a contradiction in terms to me | 10:53.04 |
| kens | Especially if the content is not photographcs type images | 10:53.09 |
| Zephyr | The images have to be served on a webserver that expects jpg reason for using that one. In regards to the anti-aliasing i'm no image guru but i know that the text went from being blurry to sharp when i added the -dTextAlphaBits and dAlignToPixels=1 | 10:55.49 |
| chrisl | anti-aliasing *adds* blur | 10:56.20 |
| kens | It can't possibly be sharp if you are sing anti-aliasing, also JPEG makes it impossible for high frequencies (ie sharp edges0 not to be blurred | 10:56.31 |
| simon91 | mupdf-devs: Hi, did you already look at http://bugs.ghostscript.com/show_bug.cgi?id=696251 (pdf_create_document) and http://bugs.ghostscript.com/show_bug.cgi?id=696259 (xref streams)? | 11:14.56 |
| | From the stuff I reported last week these are the only critical bugs, I think. So I would be grateful to have them in the next release. | 11:16.22 |
| tor8 | simon91: I have not looked at them yet. they're in paulgardiner's area of code. | 11:31.08 |
| Zephyr | Thanks for the help, seems like some of my pdf's are using quite a bit of transparency and overlapping images. guess i just have to use the extra computation time. | 11:34.45 |
| chrisl | It's still surprising they'd be taking as long at 75dpi..... not impossible, though | 11:35.30 |
| Zephyr | the dpi varies a bit from pdf to pdf depending on their size because i want a final image of a specific dimension. some of them are run closer to 150 dpi | 11:36.40 |
| simon91 | tor8, paulgardiner: Ok. just ping me at any time if you have questions about those fixes. thanks | 11:37.31 |
| tor8 | chrisl: I managed to coax fontforge into merging DroidSans and DroidSansFallback into one font which has the yen character for MuPDF. | 12:32.28 |
| chrisl | tor8: great, and when he comes back with a another substitution that doesn't work? Where do we stop?? | 12:34.10 |
| Robin_Watts | tor8: There is a ttfxxxx program somewhere that disassembles/reassembles fonts to/from xml. | 12:35.22 |
| | That might be a better route. | 12:35.29 |
| chrisl | The other problem is that fontforge munges the glyph ordering in fashion so the GS substitution doesn't work | 12:36.16 |
| Robin_Watts | http://sourceforge.net/projects/fonttools/ | 12:42.22 |
| | And all the tools that google use for the noto fonts are in their public git repo | 12:42.43 |
| tor8 | chrisl: well, even I think that missing the Yen symbol in our CJK font is a bit embarrassing. | 12:42.44 |
| chrisl | tor8: the droid Japanese font doesn't have a n Yen symbol | 12:43.09 |
| tor8 | Robin_Watts: fontforge did a decent job of making a TTC with shared glyph tables so we can get horizontal and vertical glyph variants without invoking opentype | 12:43.17 |
| | chrisl: yeah, because it's probably designed to be used as a fallback for when droidsans is missing a glyph | 12:43.36 |
| chrisl | I'm heading out for a bit, I'll look at it more when I get back | 12:43.54 |
| tor8 | but then it doesn't make a lot of sense to have even the basic ASCII characters in there, which it does | 12:44.03 |
| Robin_Watts | Oh, no henry, so no meeting ? | 14:18.00 |
| kens | Henrys sent an email sayig no meeting | 14:18.13 |
| Robin_Watts | kens: Yeah, I'd forgotten. | 14:18.23 |
| paulgardiner | I have some recollection of today's meeting having been cancelled. Is that right? | 14:25.43 |
| kens | Correct yes | 14:25.57 |
| paulgardiner | ta | 14:26.03 |
| marcosw | no meeting? why am I awake? | 14:32.30 |
| rayjj | it's a bear trying to spot an intermittent failure that has different symptoms every time :-( | 14:34.57 |
| Robin_Watts | rayjj: That's Marriage for you. | 14:37.02 |
| rayjj | Robin_Watts: ha ha | 14:37.19 |
| tor8 | mvrhel_laptop: so what was that build error you mentioned yesterday? | 14:37.31 |
| mvrhel | oh yes | 14:37.39 |
| Robin_Watts | missing gl stuff on 'doze ? | 14:37.51 |
| mvrhel | in windows the gl project did not build and in linux it also failed | 14:38.02 |
| | when I did a clean check out in linux the build failed | 14:38.24 |
| tor8 | mvrhel: huh. it builds clean here, both in my pristine WinXP+VS2005 virtualbox and on my debian. | 14:38.28 |
| mvrhel | odd | 14:38.35 |
| | hold on let me look at the error | 14:38.49 |
| tor8 | on linux you might need more system dev packages installed than before | 14:38.50 |
| mvrhel | ok. it cant find <GLFW/glwd.h> in windows | 14:39.40 |
| tor8 | on ubuntu/debian you need the libgl1-mesa-dev package | 14:39.49 |
| mvrhel | GLFWindow is not defined | 14:39.55 |
| | tor8 ok, let me add that | 14:40.04 |
| | on my ubunut | 14:40.10 |
| tor8 | mvrhel: which file is trying to include <GLFW/glwd.h>? | 14:42.48 |
| mvrhel | so in linux after adding libg11-mesa-dev I get GL/gl.h no such file | 14:43.13 |
| | in glfw3.h | 14:43.21 |
| | on windows gl.app.h is the issue | 14:43.48 |
| | gl-app.h | 14:44.11 |
| tor8 | mvrhel: that's weird ... I can't find the string 'glwd.h' anywhere in the thirdparty/glfw repository | 14:44.22 |
| mvrhel | opps | 14:44.30 |
| | that is because I typed it wrong | 14:44.38 |
| | <GLFW/glw3.h> | 14:44.48 |
| | 3 not d | 14:44.55 |
| | at least they rhyme | 14:45.00 |
| tor8 | mvrhel: and you've run 'git submodule update --init'? | 14:45.06 |
| mvrhel | yes | 14:45.10 |
| | well I did on linux | 14:45.27 |
| | I may have left the init off on windows | 14:45.37 |
| | let me try that | 14:45.39 |
| tor8 | and do you have a thirdparty/glfw/include/GLFW/glfw3.h file? | 14:45.42 |
| | mvrhel: do you have 'mesa-common-dev' installed on ubuntu? | 14:46.54 |
| | I can't remember exactly which package has the opengl headers on linux | 14:47.21 |
| mvrhel_laptop | yes the file is there | 14:47.40 |
| | hold on let me rebuild | 14:48.09 |
| Robin_Watts | Just trying a batch build of all possible variants on my new PC (first time it's ever built MuPDF) | 14:48.49 |
| tor8 | and the mupdf-gl project properties has ..\..\thirdparty\glfw\include in the C/C++ > General > Additional Include Directories? | 14:48.51 |
| mvrhel_laptop | tor8 : so on windows I also get an file not found error mupdf.ico | 14:49.59 |
| | s/an file/a file/ | 14:50.09 |
| | let me look at the properties | 14:50.20 |
| tor8 | you sure you're not using stale .vcproj files? | 14:50.45 |
| mvrhel_laptop | yes | 14:50.58 |
| tor8 | I saw that your recent commit on mvrhel/master has clobbered mupdf.sln, replacing .vcproj entries with .vcxproj | 14:51.14 |
| mvrhel_laptop | oh darn | 14:51.26 |
| | I will fix that | 14:51.30 |
| | let me do this | 14:51.52 |
| tor8 | the fz_buffer_prinf case for RGB also looks funny: fz_buffer_printf(ctx, fzbuf, "0%f 0%f 0%f rg\n", col[0], col[1], col[2]); | 14:51.59 |
| mvrhel_laptop | I will revert those back and rebuild | 14:52.03 |
| tor8 | those 0's look out of place | 14:52.07 |
| mvrhel_laptop | oh yes | 14:52.12 |
| | let me remove those | 14:52.17 |
| | I was having a very weird issue and I stuck those in temporarily | 14:52.40 |
| | That was before I saw how the pdf content for the widget was getting executed based upon the begin marker location | 14:53.41 |
| | and I had a really odd thing happening | 14:54.06 |
| | tor8 so give me a few minutes to revert the projects back and try to build from there | 14:54.40 |
| | oh it was just the sln file | 14:55.23 |
| | tor8: opengl on windows is now happy | 15:01.43 |
| | apparently the project files were screwed up | 15:01.56 |
| | the only error now is the file not found | 15:02.03 |
| | mupdf.ico | 15:02.06 |
| | in gl-winres.c | 15:02.20 |
| | in gl-winres.rc | 15:02.25 |
| | can't type this morning | 15:02.32 |
| tor8 | mvrhel_laptop: hm. I might've forgotten to add that one to the commit. | 15:02.48 |
| | just copy platform/x11/mupdf.ico to platform/gl for now | 15:03.08 |
| mvrhel_laptop | ok | 15:03.13 |
| tor8 | it's the same file | 15:03.14 |
| Robin_Watts | In the Debug win32 build, I get: | 15:03.18 |
| | ..\gl\gl-winres.rc(1) : error RC2135 : file not found: mupdf.ico | 15:03.42 |
| | ..\gl\gl-winres.rc(2) : error RC2135 : file not found: mupdf.ico | 15:03.44 |
| | so I can confirm there is an issue. | 15:03.49 |
| | DebugOpenssl x64 is failing too. | 15:04.19 |
| mvrhel_laptop | tor8: that fixed it | 15:04.30 |
| | it all builds now | 15:04.35 |
| Robin_Watts | DebugOpenssl|Win32 failing too. | 15:04.38 |
| tor8 | Robin_Watts: yes, I see the file is missing here too. | 15:04.57 |
| | Release doesn't link properly, something wrong with the main/WinMain crap | 15:05.18 |
| Robin_Watts | something is up with the dependencies on ReleaseOpenssl|x64 I think. | 15:06.04 |
| mvrhel_laptop | ok. so I fixed my commit on my repos. The sln file is no longer getting blasted and I fixed the issue with the print statement | 15:06.16 |
| tor8 | mvrhel: why is there a space before the first float in gray and cmyk but not in rgb? | 15:16.07 |
| mvrhel_laptop | hmm because... | 15:19.08 |
| | hold on | 15:19.17 |
| | no sure why any have spaces. let me clean that up | 15:19.59 |
| | ok fixed that | 15:21.29 |
| tor8 | mvrhel_laptop: that looks reasonable to me, but you might want to get paulgardiner to take a look since he's a lot more familiar with that code | 15:24.25 |
| mvrhel_laptop | tor8: ok thanks, I will do that | 15:24.43 |
| | paulgardiner: are you around? | 15:25.23 |
| paulgardiner | I'm not sure I'm exactly familiar with anything in MuPDF these days. :-) | 15:25.30 |
| | What area is it? | 15:25.40 |
| mvrhel_laptop | oh it is in the forms stuff | 15:27.13 |
| | I added some support for the list box version of the combo box | 15:27.26 |
| | so on my repos is a commit | 15:27.32 |
| paulgardiner | Got "The gateway did not receive a timely response from the upstream server or application." from http://git.ghostscript.com/?p=ghostpdl.git;a=summary | 15:27.39 |
| mvrhel_laptop | most of the changes are in pdf-appearance.c | 15:27.40 |
| | paulgardiner: I added a pdf_update_listbox_appearance which will use the proper items for the UI display when there items consist of an export value and a list value, as well as hightlight the currently selected items | 15:29.05 |
| | s/when there/when the/ | 15:29.20 |
| paulgardiner | I've forgotten where to go to see your repo | 15:29.37 |
| mvrhel_laptop | http://git.ghostscript.com/ then its the mupdf/mvrhel | 15:30.08 |
| | hmm timed out.... | 15:30.21 |
| | something is going on | 15:30.28 |
| | http://git.ghostscript.com/?p=user/mvrhel/mupdf.git;a=summary | 15:30.42 |
| chrisl | It's been happening occasional - a refresh should make it work | 15:30.53 |
| mvrhel_laptop | paulgardiner: http://git.ghostscript.com/?p=user/mvrhel/mupdf.git;a=commit;h=007d0fc04d362bf33445dfb75e465edcdb53d46e | 15:31.12 |
| paulgardiner | I can't say I've checked every detail, but I see nothing untoward in there | 15:36.31 |
| mvrhel_laptop | paulgardiner: ok. thanks for having a look | 15:38.03 |
| | bbiab | 15:46.48 |
| | off for lunch | 18:31.45 |
| Daniel__ | Hello, I'm working with MuPDF library and I'm having some problems when trying to insert a page into an empty pdf_document. Can anyone help me ? Thanks. | 21:28.52 |
| simon91 | Daniel: are you using git master? | 21:32.17 |
| | pdf_create_document is currently broken. See http://bugs.ghostscript.com/show_bug.cgi?id=696251 | 21:33.54 |
| | Daniel: if that's the problem you can run 'git checkout 1.7 && git submodule update && make' | 21:35.02 |
| mvrhel | ok I see why I was having opengl issues on linux for mupdf. my ubuntu version had reached end of life so the package was not getting installed. upgrading now... | 21:39.50 |
| Daniel__ | simon91: Yes, I'm having the same problem like the one described in the bug. pdf_trailer return NULL and from there the actual page insertion cannot continue. | 21:40.25 |
| simon91 | Daniel__: is all you want creating empty pdfs? | 21:41.47 |
| Daniel__ | simon91: well, I want to extract a page from a pdf_document (for that I can use pdf_load_page) and with that page I want to create a new pdf_document and save it. | 21:44.17 |
| | and for this process I saw that the easiest method would be to create an empty pdf_document and attach to it the page that I want. Then save the document to drive. | 21:46.33 |
| simon91 | Daniel__: so you want to extract a single page from the doc? | 21:47.18 |
| Daniel__ | Yes | 21:47.27 |
| simon91 | This is supported by the mutool program included in mupdf | 21:48.16 |
| Daniel__ | aa, ok, I didn't know that :) | 21:49.22 |
| simon91 | if you ran make, you find it in build/debug/tools/mutool | 21:49.34 |
| | Daniel__: good night i have to leave know. | 21:50.05 |
| Daniel__ | ok, thanks for the support, good night | 21:51.13 |
| ThatGuy_ | Hi, I can't get mudraw to convert an oxps document to PDF | 23:07.50 |
| | mudraw prints the following two messages repeatedly, then crashes: | 23:08.29 |
| | error: pdf device supports only base 14 fonts currentlywarning: Ignoring error during interpretation | 23:08.42 |
| | error: pdf device supports only base 14 fonts currently | 23:08.56 |
| | warning: Ignoring error during interpretation | 23:09.01 |
| | (ignore the first line) | 23:09.08 |
| | any idea what the problem is? | 23:09.42 |
| | the error is thrown by the pdf_dev_font function in pdf-device.c | 23:10.57 |
| rayjj | ThatGuy_: without seeing your input doc, it's hard to say, but I suspect that the problem is with the fonts ;-) | 23:12.39 |
| | ThatGuy_: does it render the input file properly ? | 23:13.42 |
| ThatGuy_ | I suspect so, too :) yes, mupdf does render the oxps file properly | 23:14.34 |
| Robin_Watts | ThatGuy_: The problem is simply that MuPDF's support for writing PDFs is not complete. | 23:15.29 |
| | As it says, it only supports pdf base 14 fonts. | 23:15.41 |
| rayjj | ThatGuy_: you _might_ be able to get ghostpdl 'gxps' to write the PDF. Ghostscript has more complete support for fonts in its pdfwrite device | 23:16.45 |
| ThatGuy_ | I see | 23:17.09 |
| | I'll try gxps | 23:17.27 |
| | thanks for your help | 23:17.34 |
| | both of you | 23:17.38 |
| rayjj | but gxps doesn't get all that much attention, so hopefully it still works (I thought I saw in the IRC logs that chrisl said it was broken, but I may be mistaken) | 23:17.48 |
| | ThatGuy_: gxps _does_ get run through our regression testing, primarily to do XPS->PDF conversion which is what most users want it for | 23:18.34 |
| | ThatGuy_: that and making sure our xpswrite device works | 23:19.14 |
| ThatGuy_ | does it do oxps->pdf as well? | 23:19.27 |
| | gxps, that is | 23:19.51 |
| rayjj | ThatGuy_: AFAIK, oxps is just OpenXPS -- it's still XPS, just the spec was issued by Microsoft to try and become an Open standard (so MS could pretend to play nice with the open source community) | 23:21.24 |
| ThatGuy_ | I see. The reason I'm asking is that Wikipedia states that "There are two incompatible XPS formats on the market" (https://en.wikipedia.org/wiki/Open_XML_Paper_Specification0,00) | 23:23.40 |
| Robin_Watts | The xps support in gxps is *basically* the same code as the mupdf stuff, just on a different graphics engine. | 23:23.54 |
| ThatGuy_ | * ) | 23:23.54 |
| rayjj | ThatGuy_: yeah, I see: http://download.microsoft.com/download/C/2/7/C27C657B-3BF1-4A83-B96B-E927798653A2/openxps-document-comparison-result.docx | 23:25.51 |
| | but it's all gobbledygook | 23:26.12 |
| ThatGuy_ | how so? | 23:26.20 |
| rayjj | ThatGuy_: well, I have an old version of Word that won't open it for one, and when I did manage to open it, it still shows a bunch of "Error Reference Source Not Found" messages | 23:28.39 |
| ThatGuy_ | is it likely that gxps won't work with .oxps files, then? that is, when the formats are incompatible | 23:30.30 |
| rayjj | and then it seems to be a description of OXPS, but I don't see what I expected -- a list of differences | 23:30.32 |
| | ThatGuy_: it's worth a try. | 23:32.56 |
| ThatGuy_ | I downloaded that document earlier, too, and couldn't make any sense of it, but I assumed that was simply because I'm not much of a programmer... the fact that you can't make sense of it either makes me think MS isn't very interested in providing a proper specification | 23:34.36 |
| rayjj | ThatGuy_: it's likely that gxps doesn't bother to check which it is and just works, particularly since (as Robin_Watts says) the XPS parser layer is pretty much the same as between gxps (that uses the Ghostscript graphics library layer below it) and mudpf (that uses fitz) | 23:34.37 |
| ThatGuy_ | just tried gxps and got the following error messages: | 23:35.00 |
| rayjj | drum rolll.... | 23:35.17 |
| ThatGuy_ | yeah, sorry :) | 23:36.12 |
| | (I ran this command: gxps -sDEVICE=pdfwrite -sOutputFile=pdffile.pdf -dNOPAUSE file.oxps) | 23:36.27 |
| rayjj | ThatGuy_: np. I was just kidding | 23:36.31 |
| ThatGuy_ | | .\xps\xpszip.c:583: xps_process_file(): cannot find fixed document sequence start part | 23:36.32 |
| | - .\xps\xpstop.c:307: xps_imp_process_file(): cannot process xps file | 23:36.37 |
| | Warning interpreter exited with error code -1 | 23:36.40 |
| rayjj | ThatGuy_: oh, well. BTW, what version of gxps are you using ? | 23:37.12 |
| ThatGuy_ | 9.18 | 23:37.21 |
| rayjj | ThatGuy_: does it work with gxps -sDEVICE=png16m -o out.png file.oxps | 23:39.59 |
| | (i.e., does it render ?) | 23:40.34 |
| | I expect that it won't | 23:40.39 |
| ThatGuy_ | well, mudraw already lets me convert oxps->png, but I'd like to preserve selectable text rather than convert everything to an image | 23:41.13 |
| | hold on, I'll try | 23:41.26 |
| | nope, same error | 23:42.18 |
| rayjj | ThatGuy_: yeah, I understand. There seem to be quite a few "free" tools to convert XPS to PDF according to google, some which you upload files to a web server | 23:43.02 |
| | ThatGuy_: if you have a simple example file that you can share, please open a bug on bugs.ghostscript.com against gxps and attach the file: http://bugs.ghostscript.com/enter_bug.cgi?product=GhostXPS | 23:44.12 |
| ThatGuy_ | I know about the web-based converters, but I'm not just trying to convert a single document - I'm trying to find a general conversion method | 23:46.04 |
| rayjj | ThatGuy_: you can label it an "enhancement" if you want (or wait for us to change the status). That way we can look into why mupdf can open it and gxps can't | 23:46.31 |
| ThatGuy_ | great idea to compare mupdf and gxps; I'll try to file a bug with a sample file attached to it | 23:47.53 |
| rayjj | ThatGuy_: and if you want to open an enhancement bug with the same file for mupdf to enhance font support, that's fine too. Not sure which one will get done first, but I suspect that gxps is more likely | 23:47.54 |
| ThatGuy_ | either one works for me :) | 23:48.13 |
| Robin_Watts | The difference between oxps and xps is (IIRC) to do with the type declaration in the file. | 23:48.19 |
| | ISTR that mupdf was updated to cope with oxps too. I wonder if that change has not been pushed into xps. | 23:48.42 |
| rayjj | just because the parser is already able to handle rendering oxps and the gxps code probably just needs to be updates | 23:48.42 |
| | Robin_Watts: right, that what I suspect. It's a bit of a problem having two code bases | 23:49.51 |
| Robin_Watts | Right. For MUPDF we have: | 23:50.33 |
| | #define REL_START_PART \ | 23:50.42 |
| | "http://schemas.microsoft.com/xps/2005/06/fixedrepresentation" | 23:50.44 |
| | #define REL_DOC_STRUCTURE \ | 23:50.45 |
| | "http://schemas.microsoft.com/xps/2005/06/documentstructure" | 23:50.47 |
| | #define REL_REQUIRED_RESOURCE \ | 23:50.48 |
| | "http://schemas.microsoft.com/xps/2005/06/required-resource" | 23:50.50 |
| | #define REL_REQUIRED_RESOURCE_RECURSIVE \ | 23:50.52 |
| | "http://schemas.microsoft.com/xps/2005/06/required-resource#recursive" | 23:50.53 |
| | #define REL_START_PART_OXPS \ | 23:50.55 |
| | "http://schemas.openxps.org/oxps/v1.0/fixedrepresentation" | 23:50.56 |
| | #define REL_DOC_STRUCTURE_OXPS \ | 23:50.58 |
| | "http://schemas.openxps.org/oxps/v1.0/documentstructure" | 23:50.59 |
| | In gs we have: | 23:51.01 |
| | #define REL_START_PART \ | 23:51.09 |
| | "http://schemas.microsoft.com/xps/2005/06/fixedrepresentation" | 23:51.11 |
| | #define REL_REQUIRED_RESOURCE \ | 23:51.12 |
| | "http://schemas.microsoft.com/xps/2005/06/required-resource" | 23:51.14 |
| | #define REL_REQUIRED_RESOURCE_RECURSIVE \ | 23:51.15 |
| | "http://schemas.microsoft.com/xps/2005/06/required-resource#recursive" | 23:51.17 |
| rayjj | waits to see if the flood has ended.... | 23:51.45 |
| ThatGuy_ | so mupdf should have the proper oxps code, and gxps should have the proper PDF font code? so it should be a matter of incorporating the missing pieces from one into the other? | 23:51.52 |
| rayjj | Robin_Watts: OK, so all we have to do for gxps is update the schema info ??? | 23:52.08 |
| Robin_Watts | ThatGuy_: It's a trivial matter of making gs respond to the _OXPS ones too. | 23:52.14 |
| Robin_Watts | is off to bed though. | 23:52.30 |
| | rayjj: Absolutely. Just if one or the other. | 23:52.41 |
| ThatGuy_ | that's awesome | 23:52.42 |
| | por que no los dos? | 23:52.58 |
| rayjj | ThatGuy_: please go ahead and open the bug against GhostXPS and attach a file. It may be pretty quick then | 23:53.07 |
| ThatGuy_ | will do | 23:53.29 |
| | thanks again for your help and your work in general | 23:53.51 |
| | Forward 1 day (to 2015/10/14)>>> | |
IRC Logs