| | <<<Back 1 day (to 2014/07/17) | 2014/07/18 |
| kens | chrisl_t530 : I may have a solution to the 'font outlines' thing | 08:00.58 |
| chrisl_t530 | kens: Oh, I may do, too...... | 08:01.15 |
| kens | Mine's in pdfwrite :-) | 08:01.23 |
| chrisl_t530 | So's mine..... | 08:01.30 |
| kens | ROFL, OK how are you approaching it ? | 08:01.45 |
| chrisl_t530 | If we skip creating pdfwrite's own enumerator for the show operation, and disable the cache, pdfwrite just gets marking operations, and has no clue where they came from | 08:02.26 |
| kens | OK I'm doing it differently. If I set the font->dir->ccache.upper to 0 then we don't cache the font (I save the upper limit so I can replace it). THis causes us to draw paths, which are captured in teh content stream, not the font. | 08:03.33 |
| | Potentially this will in the future allow me to capture type 3 fonts with outlines instead of bitmaps, for the 'fallback' cases. | 08:04.10 |
| chrisl_t530 | Hmm, really? I wonder why using -dNOCACHE doesn't work, then | 08:04.18 |
| kens | chrisl_t530 : because we don't usually bitmap characters at all. So in general we don;t ever use the cache | 08:04.45 |
| chrisl_t530 | Yeh, but all -dNOCACHE does is set font->dir->ccache.upper to 0 | 08:05.18 |
| kens | In this case, to make it work for all fonts, I will add a new device parameter which will force all fonts through the fallback route, and also will disable the cache. | 08:05.18 |
| | chrisl_t530 : Yes but most fonts never go there | 08:05.30 |
| | THe second part is to force all fonts to go through the fallback so they try to bitmap | 08:05.48 |
| chrisl_t530 | Hmm, I think we're doing the same thing in different ways..... | 08:06.28 |
| kens | Probably, but I like my way better :-) | 08:06.38 |
| chrisl_t530 | My way doesn't require any new options | 08:06.57 |
| kens | Because in the future I can use it to capture outlines for fallback fonts, without disturbing cases which we do handle | 08:06.57 |
| | chrisl_t530 : Yeah, but I want it as a new option. I want it to be very explicit about what's going on. One of the problems with the pswrite thread is people using the 'feature' which was never a feature at all. THIs way it really is. | 08:07.47 |
| chrisl_t530 | So, where do you force the "fallback" case to happen? | 08:08.08 |
| kens | In pdf_text_process | 08:08.29 |
| | line 3473 I just skip over the processing and jump straight to 'default' | 08:08.54 |
| | default_impl that is | 08:09.18 |
| chrisl_t530 | Okay, well, I'm happy with either - I was hoping to put together a Postscript based solution, but I can't see that working..... | 08:09.37 |
| kens | I saw the comments about it, but I wasn't happy with that, its too fragile. And it wouldn't work with XPS or PCL | 08:10.09 |
| chrisl_t530 | Well, I think ps2write/pdfwrite will preserve the "charpath" as a tr mode, won't it? | 08:11.10 |
| kens | Yes it will | 08:11.18 |
| | Well, it tries to anyway | 08:11.26 |
| chrisl_t530 | And using pathforall to "hide" the charpath won't (or shouldn't) work on certain fonts | 08:11.55 |
| kens | OK I'm going to cluster test this, then I'll figure out a new switch | 08:12.04 |
| | chrisl_t530 : it certainly *shouldn't* work :-) | 08:12.25 |
| | THis test is going to produce a bazillionlittle diffs :-( | 08:12.54 |
| chrisl_t530 | I cluster test my solution (forcing it through the "flatten fonts" case), and I was surprised there were only about 1k tests with differences - I really thought it would affect almost all | 08:13.27 |
| kens | I'm forcing the outlines for now as well. I'm expectin *many* diffs. | 08:13.54 |
| | It'll be interesting to see if we get similar results :-) | 08:14.33 |
| chrisl_t530 | Like I say, I expected very nearly all pdfwrite/ps2write tests to show differences - a thousand or so test cases seemed too few | 08:14.52 |
| kens | I'll let you know..... | 08:15.11 |
| | Or you cna just look at the dashboard as well | 08:15.25 |
| chrisl_t530 | It will be interesting - I wondered if mine was missing cases, but it's hard to see how...... | 08:15.58 |
| kens | Two different approaches should cover the bases, if we get the same results, I guess we know we tested reasonably well | 08:19.22 |
| chrisl_t530 | Well, I like handling where I did because I figured there was no chance of getting anything font like without going through gdev_pdf_text_begin()..... | 08:20.15 |
| kens | Ah but for later, I want to be able to do this without breaking all fonts | 08:20.34 |
| | Its a good step along the way to getting type 3 fonts that aren't bitmaps when we do have to fallback for weird fonts | 08:21.36 |
| chrisl_t530 | That would be possible in gdev_pdf_text_begin() - but it doesn't matter. I was really only interested that, for once, pdfwrite didn't die horribly after a change like that | 08:21.51 |
| kens | It did when I tried to force the accumulator to install and pick up the outlines :-( | 08:22.20 |
| | More work needed there I'mafraid | 08:22.32 |
| chrisl_t530 | Yeh, that seemed overkill for this case | 08:22.53 |
| kens | Oh sure, infact for this use its a bad idea, because we end up with fonts again. The only reason I'm looking at this is because of the cases where we end up rendering a bitmap type 3 font. I'd rather have an outline type 3 font. We've discussed it a few times | 08:23.45 |
| chrisl_t530 | Yep. My motivation was that the guy did come through with a use case that sort of makes sense - although it is bonkers that those applications fail so miserably with an embedded font. | 08:25.53 |
| kens | Its hardly our fault. I was also kind of miffed that they implied we shouldn't do anythign without consulting them and 'we've broken their software' when they were hacking on a device in the first place, and ignored teh (many, many) warnings we published about it being deprecated. | 08:27.22 |
| | But, I figured it would help me get to somewhere I wanted to go, if I could make it work. | 08:27.51 |
| | The thread was bizarre in many places " We had to switch to ps2write, but we've had problems with ps2write output before, and so I'm hoping that those problems were bugs and that the bugs have been fixed by now" And did you report those as bugs ? If he haqd he would know they'd been fixed, if he didn't, well....... | 08:29.23 |
| chrisl_t530 | And "what about support for Level 1 printers" - REALLY???? | 08:29.55 |
| kens | Yeah, when was the last time someone made a level 1 printer ? | 08:30.11 |
| | Any that are still running must be working on hand-crafted consumables..... | 08:30.33 |
| chrisl_t530 | And "portable Postcsript"? FFS do you know anything about the language?!?! | 08:31.21 |
| kens | Clearly not, as I pointed out :-) | 08:31.30 |
| chrisl_t530 | But as so often happens, if we show willing to help workaround a bug/limitation in someone else's software, it probably makes us look quite good | 08:32.26 |
| kens | Nobody in the know believes level 1 PostScript is portable. But of course, if you get all your information from Wikipedia and other authoritative online sources..... | 08:32.35 |
| | Wow, lots of diffs | 08:33.03 |
| | And a huge pile of seg faults, which is unexpected | 08:33.19 |
| chrisl_t530 | Ah, well I got no seg faults :-) | 08:33.37 |
| | And, like I said, I bet a *real* Level 1 printer couldn't actually handle the output from pswrite anyway | 08:34.12 |
| kens | 9579 diffs in pdfwrite | 08:34.16 |
| | chrisl_t530 : Very possibly not | 08:34.26 |
| chrisl_t530 | Well, considering the resource limits when Level 1 was current | 08:34.51 |
| kens | Probably depends how many fonts you use | 08:35.12 |
| chrisl_t530 | Images, shadings etc etc | 08:35.41 |
| kens | Well I'd better look at these seg faults first I guess | 08:36.13 |
| | Umm, looks like I'm breaking type 3 fonts | 08:41.53 |
| chrisl_t530 | Odd.... | 08:42.28 |
| kens | Yeah, the font pointer is NULL, which is quite bizarre. | 08:42.44 |
| | Maybe there's something I need to set up in text_process that I missed. | 08:43.02 |
| | AH, looks like I haven't created a type 3 font to populate | 08:46.05 |
| | Presumably that's done somewhere else, the usual crap of pdfwrite | 08:46.48 |
| chrisl_t530 | I'm confused - that doesn't sound like you are degenerating glyphs into "bare" marking ops...... | 08:46.58 |
| kens | Its complicated....... | 08:47.11 |
| chrisl_t530 | Isn't it always?? | 08:47.23 |
| kens | We take different code paths for type 3 fonts (input as type 3 fonts) through the charproc accumulator | 08:47.35 |
| | And it assumes we already have built a type 3 font to hold the result. Naturally this is created 'somewhere else' | 08:48.02 |
| chrisl_t530 | Okay, I'll leave you to it - I have to make some phone calls..... | 08:48.34 |
| kens | NP | 08:48.39 |
| | Its my code, and I'll need to solve this for the general case eventually | 08:48.52 |
| jogux | gotta love appstore reviews: "Was great until update | 09:12.07 |
| | Now I can not open any .xlsx files. Very frustrating for working on the go. ". | 09:12.07 |
| kens | Hmm, still some seg faults in PCL. lots of diffs in PS/PDF | 09:24.40 |
| | path+fill is bolder than font rendering it seems | 09:25.11 |
| chrisl_t530 | I think we established that when we did the fapi stuff | 09:26.06 |
| kens | Yeah, just an observation. Looks like I should fix PCL because I see a *lot* of diffs | 09:26.29 |
| | 9961 of 14344 in pdfwrite | 09:27.01 |
| | 5594 of 9558 in ps2write | 09:27.23 |
| chrisl_t530 | I got Differences in 1463 of 14344 pdfwrite test(s): | 09:27.37 |
| | And Differences in 839 of 9558 ps2write test(s): | 09:28.02 |
| kens | To be honest, mine is more like what I'd expect | 09:28.05 |
| chrisl_t530 | Both of which I felt were oddly low.... | 09:28.21 |
| kens | Yes, I'd expect small differences on pretty much every page with text, which is most of them | 09:28.43 |
| | looks like a long task ahead, best I fix PCL first | 09:29.09 |
| chrisl_t530 | Yeh, but like I said, I can't see how you get text without going through the enumerator creation | 09:29.18 |
| kens | Beats me :-) | 09:29.27 |
| | If you like you could find a file where I see a diff and you don't, and then see what your fix produces in the way of a PDF file | 09:30.05 |
| | Given I have so many files with diffs, it shouldn't be hard to find one | 09:30.22 |
| chrisl_t530 | Well, the problem is, my solution is one problem only - it's no help with your ultimate goal | 09:30.55 |
| kens | True, but if you really want to know what's going on it might tell you | 09:31.26 |
| chrisl_t530 | At the moment, I have two partially non-functional Ubuntu computers I could really do with fixing :-( | 09:32.03 |
| kens | Seems like a better use of your time then. As I said, I *expected* a lot of diffs. | 09:32.28 |
| chrisl_t530 | OTOH, if you'd like some help with your solution, I wouldn't mind pitching in | 09:33.16 |
| kens | Up to you, I'm hacking on it at the moment, findong out all the places I need to skip over things to prevent cxrashes | 09:34.08 |
| | I think I've sorted PCL (hacky temporary solution), just need to test it first | 09:34.38 |
| chrisl_t530 | You can let me know - I would *really* like my two main computers fully functional again! | 09:35.06 |
| kens | Then I'd say go fix those, I'm progressing here, even if slowly | 09:35.33 |
| chrisl_t530 | Trouble is, I've no clue what caused the problem - other that something in the recent updates :-( | 09:36.31 |
| kens | :-( | 09:36.40 |
| | OK lets see if anything is still broken | 09:37.17 |
| | Yay, all seg faults sorted | 09:56.06 |
| | Now a mere 15000 diffs to compare..... | 09:56.27 |
| | Interesting, some PCL content is lighter when made into filled paths, whereas PostScript is bolder. | 10:23.54 |
| | Ah, its a lower resolution | 10:27.38 |
| zeniko | tor8: Robin_Watts: (or FTL) there are 10 small bug fixes on zeniko/mupdf for review | 14:10.19 |
| tor8 | Robin_Watts_: zenikos 10 fixes all LGTM, but you might want to give them a look as well before I push them? | 14:37.23 |
| Robin_Watts_ | tor8: Nah, go for it. I'm buried at the mo. | 15:02.24 |
| rayjj | morning, all | 15:38.22 |
| kens | morning ray | 15:38.31 |
| rayjj | got my son off to camp... | 15:38.35 |
| | hi, mvrhel_laptop | 15:38.42 |
| mvrhel_laptop | morning rayjj | 15:38.54 |
| rayjj | mvrhel_laptop: In case I get fed up with real work, I'd like to track down what I need to build gsview. | 15:39.28 |
| mvrhel_laptop | rayjj: you should be able to build the main executable | 15:39.53 |
| rayjj | mvrhel_laptop: after I was offline the other day you said I might be missing some "other" stuff | 15:39.54 |
| mvrhel_laptop | only for the installer | 15:40.05 |
| rayjj | mvrhel_laptop: first, have you tried with VS 2013 Express (I started with that for now) | 15:40.37 |
| mvrhel_laptop | rayjj: you wont be able to build some of the other projects since they are windows 8.1 applications | 15:40.38 |
| | rayjj: no I have VS2013 pro | 15:40.51 |
| | rayjj: but you should be able to build gsview | 15:41.21 |
| | as it is just dlls and the main gsview application | 15:41.41 |
| | which is a wpf c# project. that should def. build | 15:42.08 |
| rayjj | mvrhel_laptop: first, what should I try in the confguration manager ? It defaulted to "Mixed Platforms". Maybe x64 or x32 ? | 15:42.34 |
| mvrhel_laptop | it should be mixed | 15:42.57 |
| | for gsview | 15:43.07 |
| | hmm let me go there | 15:43.24 |
| | hold on | 15:43.27 |
| rayjj | mvrhel_laptop: OK. Note that when I select "Mixed" it has Win32 for most parts and "Any CPU" for gsview | 15:44.19 |
| mvrhel_laptop | hold on | 15:44.29 |
| | so I have x64 seet | 15:45.29 |
| | set | 15:45.31 |
| | which means all the libraries are built with x64 except for the c# wpf project which is built with anyCPU | 15:45.58 |
| rayjj | mvrhel_laptop: the first Error I get is: Error1Application Configuration file "App.config" is invalid. Could not find file 'C:\Artifex\gsview\mupdf\platform\winrt\gsview\App.config'.C:\Artifex\gsview\mupdf\platform\winrt\gsview\App.configgsview | 15:46.07 |
| | then: Error2error C1083: Cannot open include file: 'mupdf/pdf-tools.h': No such file or directoryc:\artifex\gsview\mupdf\platform\winrt\mupdfwinrt\muctx.h111mupdfnet | 15:46.35 |
| mvrhel_laptop | perhaps I did not get something checked in. rayjj: let me do a clean checkout later today ad make sure all is ok | 15:47.00 |
| | s/ad/and/ | 15:47.06 |
| | rayjj: did you have a list of things that you found that needed to be fixed? | 15:47.50 |
| | I know I have a few things | 15:47.58 |
| rayjj | mvrhel_laptop: BTW, what I have as the remote.origin is /home/mvrhel/repos/mupdf.git | 15:49.16 |
| mvrhel_laptop | rayjj: yes | 15:49.33 |
| | and it is the win_desktop branch | 15:49.43 |
| rayjj | morning, kens | 15:49.43 |
| | (I just noticed -- sorry, kens) | 15:49.54 |
| | mvrhel_laptop: right, that's what I have in that directory | 15:50.27 |
| | mvrhel_laptop: can you see if you have App.config -- that's the first error message, and it shows up in the Solution Explorer | 15:55.03 |
| | mvrhel_laptop: maybe you forgot to git add it ? | 15:55.30 |
| | mvrhel_laptop: I started with just libmupdf and I get: Error1error C2065: 'pdf_font_DroidSansFallbackFull' : undeclared identifierc:\artifex\gsview\mupdf\source\pdf\pdf-fontfile.c1431libmupdf | 15:57.55 |
| mvrhel_laptop | rayjj: ok. let me wrap up what I am doing in SOT for a sec | 15:58.43 |
| Robin_Watts_ | rayjj: That smells like a generated issue. | 15:58.53 |
| mvrhel_laptop | right | 15:59.14 |
| rayjj | Robin_Watts_: that area is dependent on NOCJKFULL | 15:59.50 |
| Robin_Watts_ | rayjj: There is a step in the build where we take the font files, and make header files with the data in. | 16:03.47 |
| | That's the 'make generated' step in unix terms. | 16:03.58 |
| | It's possible that the windows rt stuff assumes that you've done a normal windows build first to setup the generated dir. | 16:04.32 |
| rayjj | Robin_Watts_: apparently that step isn't a precursor to libmupdf | 16:04.49 |
| mvrhel_laptop | this whole thing is not really ready for others. the solution has both winrt projects and the gsview project. however you should be able to build gsview. | 16:05.28 |
| rayjj | Robin_Watts_: at least for the winrt platform, as you've said. I'll try building mupdf first then | 16:05.33 |
| mvrhel_laptop | certainly you need to build mupdf | 16:05.44 |
| Robin_Watts_ | rayjj: The generated step is a precursor to libmupdf on the normal VS project. | 16:06.24 |
| mvrhel_laptop | it is here too | 16:06.31 |
| rayjj | mvrhel_laptop: OK, you can go back to having fun with SOT -- I'll just play around with it, but the App.config does concern me | 16:06.40 |
| mvrhel_laptop | let me stop what I am doing and work on this now | 16:06.42 |
| | rayjj: I think you need to come over to SOT | 16:07.02 |
| rayjj | ahhhhhhhhhh!!!!! | 16:07.19 |
| rayjj | runs screaming | 16:07.25 |
| mvrhel_laptop | hmm looks like the dependencies are not set up correctly. let me fix that first | 16:07.47 |
| rayjj | So here I am, back working on ghostscript clist crashes. Whew! that was quite a nightmare where somebody mentioned that I should work on SOT. | 16:08.54 |
| | :-) | 16:09.01 |
| mvrhel_laptop | :) | 16:09.12 |
| | rayjj: there are dependency issues in the project I can see | 16:09.35 |
| | let me try to fix those today as well as make sure all the files are there | 16:09.47 |
| | but I want to fix this one offset angle thing in SOT first | 16:10.44 |
| | for the pie charts | 16:10.48 |
| | it is a low hanging bug fix | 16:10.56 |
| rayjj | mvrhel_laptop: libmupdf had dependencies listed for generated, gsview, libthirdpary and mupdfnet, but none were checked by default. I checked all but gsview | 16:11.32 |
| mvrhel_laptop | rayjj: will look at this in a bit | 16:12.30 |
| | libmupdf is not dependent upon mupdfnet certainly | 16:13.13 |
| | anyway. let me wrap up this thing first | 16:13.39 |
| | SOT that is | 16:13.44 |
| kens | goodnight folks..... | 16:22.41 |
| rayjj | Robin_Watts_: It seems that 'clean generated' doesn't delete the generated files -- there was an almost empty one generated when I tried the winrt gsview build and when I did rebuild generated for win32 mupdf it didn't clean it out, so I had to manually delete it | 16:24.32 |
| | Robin_Watts_: generated/gen_font_cjk_full.h | 16:25.39 |
| Robin_Watts_ | No, clean generated doesn't. | 16:30.40 |
| | Is it working for you now ? | 16:30.46 |
| rayjj | Robin_Watts_: there's an error in the 'clean' part of the nmake -- it needs to be: del /q ..\..\generated (was missing one level of parent and was trying to delete platform/generated | 16:32.43 |
| | Robin_Watts_: I'll patch that in the mupdf repo | 16:33.09 |
| mvrhel_laptop | ugh. vs 2010 crashes again | 16:40.42 |
| Robin_Watts_ | rayjj: Ah, thanks. | 16:40.56 |
| rayjj | Robin_Watts_: please check my patch | 16:41.22 |
| | Robin_Watts_: turns out it was OK except for the "Debug" configuration | 16:41.49 |
| Robin_Watts_ | looks good to me. | 16:45.51 |
| rayjj | Robin_Watts_: thanks. | 16:46.03 |
| | Robin_Watts_: next problem: Building mupdf/libthirdparty with VS 2005 works, but with 2013 I get a problem with mujs/jsi.h line 27: Error4error C2059: syntax error : 'sizeof' | 16:56.48 |
| | (why mvrhel_laptop doesn't see this, I don't know). Note I am just doing "master" mupdf in a directory cloned from /home/git/mupdf.git | 16:57.58 |
| Robin_Watts_ | I don't see sizeof used on line 27 of mujs/jsi.h | 16:58.21 |
| rayjj | (leaving gsview alone for a bit, but I saw this same error on mvrhel_laptop's gsview (win_desktop branch) | 16:58.45 |
| mvrhel_laptop | weird. I have to go for a bit. wife picking me up at car shop where I have been. bbiab | 17:00.32 |
| Robin_Watts_ | rayjj: I still can't see sizeof there. | 17:00.35 |
| rayjj | Robin_Watts_: I know, I don't see sizeof either. Note I also get some other errors: | 17:00.41 |
| | 46IntelliSense: expected an identifierc:\Artifex\mupdf\thirdparty\mujs\jsi.h2721libthirdparty | 17:00.42 |
| | 47IntelliSense: identifier "x" is undefinedc:\Artifex\mupdf\thirdparty\mujs\jsi.h2772libthirdparty | 17:00.44 |
| Robin_Watts_ | rayjj: pastebin all the errors please. | 17:00.56 |
| | In fact, pastebin everything :) | 17:01.07 |
| rayjj | that's all three (from building libthirdparty) | 17:01.21 |
| Robin_Watts_ | rayjj: That doesn't look like stuff from the "Output" window. | 17:02.07 |
| | That looks more like from the "Errors" window ? | 17:02.13 |
| rayjj | Robin_Watts_: it was. From the Output Window I see: 1>c:\artifex\mupdf\thirdparty\mujs\jsi.h(27): error C2059: syntax error : 'sizeof' | 17:03.40 |
| Robin_Watts_ | rayjj: Please pastebin the entire output window. | 17:03.58 |
| rayjj | Robin_Watts_: http://pastebin.com/vc5WisNF | 17:05.24 |
| | Robin_Watts_: mujs is first | 17:05.46 |
| Robin_Watts_ | OK, so it looks like this VS only section of the header is not working for VS2013. | 17:08.09 |
| | Which is odd. | 17:08.14 |
| rayjj | I bet mvrhel built mupdf with something other than VS 2013 and so libthirdparty was already laying around :-/ | 17:08.22 |
| Robin_Watts_ | But maybe they updated it. | 17:08.27 |
| | so... after the #ifdef _MSC_VER do: | 17:08.51 |
| | #if _MSC_VER < 1800 | 17:09.15 |
| | and add a matching #endif after #define NAN | 17:09.27 |
| | rayjj: I suspect you are right. He probably built mupdf with VS2005 or thereabouts, cos that's what the solution/projects are set up for. | 17:10.40 |
| rayjj | Robin_Watts_: a BUNCH more errors now (6) in jsbuiltin.h -- looks like the stem from the two uses of "static inline void ..." on lines 38 and 44 | 17:13.30 |
| | Robin_Watts_: IIRC, VS uses __inline | 17:13.52 |
| Robin_Watts_ | Ok, in the stuff you just #ifdeffed out... | 17:14.13 |
| | There is a #define inline __inline | 17:14.20 |
| | You need to move that to be before the #if _MSC_VER < 1800 you just added. | 17:14.41 |
| rayjj | Robin_Watts_: right. I did that and it works now | 17:15.46 |
| | do you want me to patch that, or do you want to ? | 17:16.06 |
| Robin_Watts_ | go for it. | 17:17.49 |
| rayjj | Robin_Watts_: there were other things that need to be outside the #if _MSC_VER < 1800 (I had unresolved refs), so I moved it to just before the #define round(x) and all is OK | 17:20.42 |
| | I snprintf was missing | 17:21.13 |
| Robin_Watts_ | fab. | 17:22.05 |
| rayjj | Robin_Watts_: I'll post a patch and push it later if you approve. I have to run an errand now... | 17:22.10 |
| Robin_Watts_ | ok, ta. | 17:23.52 |
| mvrhel_laptop | rayjj: I did not build mupdf with a different project | 19:33.41 |
| | or Robin_Watts_ | 19:34.43 |
| | i really dislike vs2010. this thing crashes all the time | 21:09.40 |
| | rayjj: SOT has burnt up my day so I did not get a chance to look at gsview. | 21:26.56 |
| | will try to have a look this weekend | 21:26.59 |
| | bbiaw | 21:27.02 |
| | Forward 1 day (to 2014/07/19)>>> | |
IRC Logs