| | <<<Back 1 day (to 2018/06/11) | 20180612 |
| paulgardiner | tor8: is your commit 957e99b045 ready to go? It would be handy to have it on master. | 11:20.10 |
| tor8 | paulgardiner: yes. I can rebase and push it. | 11:38.23 |
| | paulgardiner: have you had a chance to try out the appearance stream changes on tor/ui? | 11:41.50 |
| paulgardiner | Oh, no, I haven't. Remind me what's on there. | 11:52.39 |
| tor8 | completely new appearance stream synthesis | 11:55.28 |
| | that's mostly it | 11:55.39 |
| | the 4 oldest commits are the most relevant ones | 11:56.04 |
| | there are still a few TODO items | 11:56.33 |
| | but the TODOs are 99% related to forms. common annotations should work. | 11:56.59 |
| RobinWattsLenovo | tor8: So, looking at Cody's issue. | 12:05.22 |
| | it seems that upgrading from VS2005 to VS2015 they changed the way custom rules work. | 12:05.47 |
| | The upgrade converts the .rules into a .props which is not quite equivalent. | 12:06.05 |
| | and it buggers the dual 64bit/32bit building I am doing. | 12:06.26 |
| | I have a few options. | 12:06.36 |
| | I could make it call via a batch file. Yuck. | 12:06.46 |
| tor8 | RobinWattsLenovo: would moving to (our fixed) premake be helpful here, we could generate vcproj files for 2005, and 2015? | 12:06.56 |
| RobinWattsLenovo | OR I could tweak our bin2coff tool so that it spots 'x64' in the path and builds 64bit with that. | 12:07.14 |
| tor8 | or make bin2coff generate two outptu files directly | 12:07.20 |
| RobinWattsLenovo | tor8: Or that. | 12:07.25 |
| tor8 | or what you said | 12:07.27 |
| RobinWattsLenovo | I'm not convinced we wouldn't hit similar problems with premake. | 12:07.53 |
| | keeping stuff as simple as possible seems best. | 12:08.07 |
| tor8 | I've no idea how premake handles custom build rules ... but I know it has them | 12:08.10 |
| RobinWattsLenovo | I would prefer to move away from the "generate both 32 and 64bit" stuff if I can find a nice way, because principle of least surprise. | 12:08.49 |
| tor8 | I think spotting '/x64/' or '\x64\' as a path element would be easiest | 12:08.56 |
| | and cleanest | 12:09.07 |
| | with the biggest hidden 'gotcha' :) | 12:09.12 |
| RobinWattsLenovo | I wonder if i can find an appropriate macro that vs sets to tell me if it's 32 or 64bit... | 12:10.04 |
| | that'd be nicest. | 12:10.08 |
| | Let me hunt. | 12:10.13 |
| tor8 | if (strstr(path, "/x64/") || strstr(path, "/X64/") || strstr(path, "\\x64\\") || strstr(path, "\\X64\\")) in addition to checking the final argument perhaps? | 12:10.27 |
| | ah you mean for the bin2coff generated exe, so it generates 32 or 64 bit depending on whether the binary itself was built 32 or 64-bit? | 12:10.57 |
| | RobinWattsLenovo: there might be a getenv() thing | 12:11.10 |
| | IsWow64Process()? | 12:12.13 |
| RobinWattsLenovo | $(PlatformName) might work. | 12:12.27 |
| tor8 | it'd be nice to be able to do cross compiles | 12:12.29 |
| | so checking the path is probably safest, IMO | 12:12.41 |
| RobinWattsLenovo | I can make the invocation be bin2coff Infile Outfile $(PlatformName) | 12:12.51 |
| | which will give us Win32 or x64 | 12:12.59 |
| | so I need to tweak the code to look for x64 instead (or as well as) 64bit. | 12:13.13 |
| tor8 | infile outfile symbolname platformname | 12:13.19 |
| | but yeah, that's even better I think | 12:13.24 |
| RobinWattsLenovo | Is there a nimbussansnarrow ? | 12:38.00 |
| | I obviously had one on my desktop, but I don't have one here. | 12:38.16 |
| | c:\artifex\mupdf.git\resources\fonts\urw\NimbusSansNarrow-Regular.cff | 12:38.42 |
| tor8 | RobinWattsLenovo: there is one, but not included in mupdf | 12:38.44 |
| RobinWattsLenovo | right. oops. | 12:38.51 |
| | tor8: A couple of commits on robin/bin2coff then. | 13:36.41 |
| paulgardiner | tor8: muso calls pdf_set_markup_appearance. Should I replace that by pdf_set_annot_default_appearance? I'm not yet understanding why that function takes font, size, etc. | 13:46.19 |
| tor8 | paulgardiner: pdf_update_annot should be all you need to call after changing the annotation properties | 13:52.23 |
| | paulgardiner: no need to call set_markup_appearance at all anymore | 13:52.32 |
| | pdf_set_annot_default_appearance is to change the font, size, and color of a FreeText annotation | 13:52.50 |
| | (badly named, but that's what the spec calls those properties...) | 13:53.22 |
| paulgardiner | Ah okay. good. | 13:54.15 |
| | tor8: just remembered something. I mentioned to you that one mode for text widgets is to wrap and adjust font size to fit a box, a mode we do support at the moment. Wasn't sure how important it was at the time, but just remembered that it's needed for signature appearance streams | 13:56.13 |
| tor8 | paulgardiner: pdf_update_appearance is also acceptable to call; it does just the appearance updating (pdf_update_annot also does some event handling) | 13:56.25 |
| | paulgardiner: you mentioned that, and I can't find the mode in the spec. | 13:56.44 |
| | or is it just something you needed for signature appearances? (those are a TODO item, waiting for when I've got widgets better hooked up so I can test it easily) | 13:57.49 |
| | RobinWattsLenovo: both commits LGTM | 13:58.35 |
| paulgardiner | That's weird. I thought I found it in the spec. Certainly not just for signatures | 13:58.58 |
| tor8 | paulgardiner: maybe I just glossed over it. if you could point me at it I'd appreciate it :) | 13:59.16 |
| paulgardiner | I'll have a look. | 13:59.31 |
| RobinWattsLenovo | tor8: Ta. | 14:15.48 |
| paulgardiner | tor8: I cannot find it in the spec either, so far at least. I may have copied Acrobat Reader's behaviour. I know I didn't do it for fun, because it really wasn't any fun at all. :-) | 14:17.00 |
| | tor8: I've just found an example file for which AR does it at least. | 14:20.55 |
| | tor8: still trying your ui branch. Now I have a link error, undefined pdf_fzbuf_print_da called from pdf_set_free_text_details. I'm not calling the latter directly. | 14:28.22 |
| tor8 | paulgardiner: try a clean build, it may be a stale object file | 14:38.25 |
| paulgardiner | Ah yeah, I fall into that trap frequently, and then forget before the next time | 14:38.59 |
| | tor8: highlight annotations are coming out black. Maybe I'm missing a call to set the color. | 14:56.39 |
| | tor8: a form field I updated changed vertical alignment | 15:02.14 |
| tor8 | paulgardiner: take a look at new_annot() in platform/gl/gl-annotate.c | 15:13.45 |
| | that might point out some properties you forgot to set | 15:13.50 |
| | I respect the default color set in the spec (which is black) | 15:14.03 |
| paulgardiner | tor8: okay the highlight color is sorted. Possibly updates are taking a lot longer. I'll have to retest on the master branch to be sure. And the alignment of text in form fields is wrong. I also found I couldn't delete annotations added to one file, but that's another problem I need to retest on master. Besides that looks to be working okay | 15:32.55 |
| tor8 | paulgardiner: yeah, I need to look into how vertical alignment is supposed to be done | 15:33.31 |
| | if there's some magic margin fuzz... there's not much guidance to be found from the adobe spec | 15:33.57 |
| paulgardiner | It's all too long ago for me to remember | 15:35.24 |
| | Ah combed text is broken | 15:37.12 |
| tor8 | and 'password' text too, I reckon | 15:38.23 |
| paulgardiner | I haven't tested signing. The appearance stream for signature fields was about the most complicated, so I'd guess that isn't working. | 15:39.49 |
| tor8 | paulgardiner: yeah, signature appearances are gone a.t.m. | 15:40.10 |
| | paulgardiner: also, WTH is combed text used for anyway? | 15:40.52 |
| | anyway, time for dinner | 15:40.58 |
| | if annotations work now, it may be worth getting this on master, and I'll work on improving the forms | 15:41.19 |
| paulgardiner | Combed text is for when a grid is provided into which to enter the characters. | 15:41.23 |
| tor8 | oh, one character per grid cell? | 15:41.37 |
| | like the old USA visa waiver forms. | 15:42.08 |
| paulgardiner | I need to check that the slow update is just my imagination, and the failure to delete annotations from one file is the same before your changes. Also, I don't know if marketing have any soon upcoming plans for form support. | 15:43.36 |
| | tor8: it wasn't my imagination. The update when I change a form field is much slower when I take on your ui branch. I'll see if I can find out why tomorrow. | 17:43.31 |
| razi | Robin_Watts: Do you have any idea about these link errors (msvc2015_32bit): https://beepaste.io/paste/view/4VHWUE ? | 17:58.14 |
| Robin_Watts | razi: hi. That looks like libresources hasn't generated properly. | 17:58.47 |
| | How up to date is your checkout? | 17:58.54 |
| | I put a commit in a couple of hours ago to try and solve problems in this aread. | 17:59.30 |
| razi | Robin_Watts: I used last git commit | 18:00.46 |
| Robin_Watts | razi: ass. let me double check here. | 18:00.59 |
| | Updating it to VS2015 now... | 18:01.51 |
| razi | Robin_Watts: Thanks | 18:02.10 |
| Robin_Watts | razi: Did you do a fresh conversion from the VS2005 solution? | 18:02.32 |
| razi | Robin_Watts: Yeah, Indeed I use a completley fresh build | 18:04.30 |
| Robin_Watts | That built fine for me. | 18:05.29 |
| | For Debug win32. | 18:05.56 |
| | and Release win32. | 18:07.20 |
| | I was doing "Build Solution", what were you doing? | 18:07.42 |
| razi | Robin_Watts: I'm trying release. Maybe the issue is that I'm using command line with wrong arguments. I run "msbuild /m mupdf.sln /property:Configuration=Release /p:Platform=Win32" | 18:08.22 |
| Robin_Watts | razi: Ah, ok, I've not tried from the command line. | 18:08.47 |
| | Does it work from the IDE? | 18:09.11 |
| | (i.e. run Visual Studio, load the solution, select "Release" "Win32" at the top, and then Build -> Build Solution? | 18:09.42 |
| razi | Robin_Watts: Please wait, I'm testing it. | 18:10.19 |
| Robin_Watts | sure. | 18:10.24 |
| razi | Robin_Watts: Same issue :/ | 18:19.00 |
| Robin_Watts | Can you pastebin the *complete* build log please? | 18:19.46 |
| | Where are you getting msbuild from? | 18:20.42 |
| | (i.e. what path?) | 18:20.48 |
| razi | Robin_Watts: This is not the part available from gui: https://beepaste.io/paste/view/BjpGpM , if there is a log file I can upload it. | 18:22.55 |
| | I mean "this is" | 18:24.04 |
| | Robin_Watts: Indeed, I also created a CI (github+appveyor) and there is same issue, so I think it is not an issue with my computer configuration. See: https://github.com/srazi/MuPDF-Win32-Release and https://ci.appveyor.com/project/srazi/mupdf-win32-release/build/VC14-x86.15 | 18:25.12 |
| Robin_Watts | razi: I'm attempting to do the same msbuild thing here. | 18:27.37 |
| | I went to the start menu, found the visual studio 2015 group and in there chose "MSBuild command prompt for vs2015" | 18:28.26 |
| | Then I ran: msbuild /m mupdf.sln /property:Configuration=Release /p:Platform=Win32 | 18:28.41 |
| | oops. | 18:28.49 |
| | then I did: cd c:\artifex\mupdf.git\platform\win32 | 18:29.05 |
| | and then I ran that command. | 18:29.09 |
| razi | Aha, I found "VS2015 x86 native tools command prompt" | 18:30.51 |
| | Robin_Watts: In an AppVeyor worker I was able to compile it successfully from Visual studio GUI. | 18:52.03 |
| Robin_Watts | Cool. | 19:08.35 |
| | So does that sort it for you? | 19:09.19 |
| razi | Robin_Watts: I hope I can compile it from command line to fix CI. Thanks for your time :) | 19:14.01 |
| Robin_Watts | no worries. | 19:16.16 |
| | Forward 1 day (to 2018/06/13)>>> | |
Log of #mupdf at irc.freenode.net.