| | <<<Back 1 day (to 2018/03/18) | 20180319 |
| sebras | Hufokus: that sounds like one approach. that way you would avoid reparsing the file when you want to do the zooming. | 03:42.07 |
| velix | vtorri: I'll try. | 04:38.55 |
| | Could anyone please be so nice and compile latest mutools for Windows for me? | 05:34.10 |
| | Can't get freeglut to compile :( | 05:51.42 |
| vtorri | velix with MSYS2 + mingw-w64 i even get : scripts/../source/fitz/time.c:85:1: error: conflicting types for 'fz_fopen_utf8' | 07:31.55 |
| velix | vtorri: Yeah, not that easy. Maybe we can set up a cross-building-bot, who delivers nightly binaries. | 08:08.26 |
| | I'll have a look in some hours. Need sleep. | 08:08.32 |
| vtorri | tor8 : with MSYS2 + mingw-w64 i even get : scripts/../source/fitz/time.c:85:1: error: conflicting types for 'fz_fopen_utf8' | 08:53.18 |
| | tor8 : i just opened MSYS2, go to mupdf 1.12 directory and run make | 08:53.39 |
| | tor8 : also plenty of " unknown conversion type character 'z' in format [-Wformat=]" messages | 08:55.00 |
| | %z is not a valid Windows printf modifier | 08:55.26 |
| tor8 | vtorri: the %z thing is not a problem; we implemented our own printf formatter to get around issues like this | 08:55.54 |
| vtorri | tor8 : so I guess that it will be available in mupdf 1.13, right ? | 08:56.45 |
| tor8 | vtorri: are you building from source or from git? | 08:57.16 |
| vtorri | tor8 : from the 1.12 release tarbal, not git | 08:57.34 |
| | tor8 : but if you want me to test right now git code, not problem | 08:58.13 |
| tor8 | if you could give the git code a quick test build, I'd appreciate it | 08:59.24 |
| vtorri | tor8 when cloning with the command on the mupdf website, i get this message : | 09:04.22 |
| | » : identifiant non valablesh: ligne 88 : export: « sha1 | 09:04.24 |
| | and | 09:04.39 |
| | » : identifiant non valablesh: ligne 88 : export: « displaypath | 09:04.40 |
| | though it seems that git clone has successfully finished | 09:05.17 |
| | same problems | 09:07.52 |
| | tor8 %z warning messages | 09:08.00 |
| | tor8 and error: conflicting types for 'fz_fopen_utf8' | 09:08.13 |
| | tor8 : http://codepad.org/TDxOVX8R | 09:09.09 |
| tor8 | vtorri: yeah, I see where it goes wrong | 09:20.17 |
| | the fz_open_utf8 windows-specific wrapper function is guarded by _MSC_VER | 09:20.36 |
| | but the use of it is guarded by _WIN32 | 09:21.11 |
| vtorri | indeed | 09:24.49 |
| | _MSC_VER is for vc++ | 09:25.01 |
| | _WIN32 for both should be sufficient | 09:25.26 |
| | tor8 : if you push the fix right now, i can test it | 09:25.44 |
| | i have some time this morning :) | 09:25.52 |
| tor8 | vtorri: in include/mupdf/fitz/system.h there's a #ifdef _MSC_VER /* Microsoft Visual C */ line | 09:26.19 |
| | at the bottom of that ifdef section is a couple of functions that should probably be under #ifdef _WIN32 instead | 09:26.42 |
| | I'm just not sure exactly which ones | 09:26.48 |
| | the ones starting with hypotf | 09:26.54 |
| vtorri | ok, checking | 09:26.57 |
| tor8 | if you add a #endif #ifdef _WIN32 just before hypotf and if that works all is good | 09:27.11 |
| | otherwise just keep moving it down until things work | 09:27.18 |
| | not sure if MSYS2 has hypotf and atoll | 09:27.31 |
| | in either case, if you add the #endif\n#ifdef _WIN32 before fz_utf8_from_wchar you should be good | 09:28.06 |
| vtorri | if it is in msdn, it is available | 09:29.05 |
| | mingw-w64 has both of them | 09:29.31 |
| tor8 | those are unix specific functions, that are called different things in windows | 09:29.57 |
| | hence the #defines for them | 09:30.03 |
| vtorri | tor8 https://msdn.microsoft.com/fr-fr/library/a9yb3dbt.aspx | 09:30.36 |
| | the one without _ exists | 09:30.47 |
| | vc++ stupidly adds a warning that one should use the ISO C++ (arg.....) version of functions without the prepended _ | 09:34.37 |
| tor8 | vtorri: huh. it used to be that msvc would complain that you should use the non-ISO version *with* the prepended _ :) | 09:35.13 |
| vtorri | ha right, with, sorry | 09:35.44 |
| | tor8 with http://codepad.org/hWAHUXiI i hit another error : | 09:36.11 |
| | build/release/libmupdf.a(pdf-annot-edit.o):pdf-annot-edit.c:(.text$pdf_annot_modification_date+0x2b0): undefined reference to `_mkgmtime32' | 09:36.25 |
| tor8 | vtorri: hmm. in source/pdf/pdf-annot-edit.c at the top, does it work if you change the ifdef _WIN32 to ifdef _MSC_VER? | 09:38.35 |
| | though you said all functions listed in msdn (of which _mkgmtime32 is one) should be available | 09:39.35 |
| vtorri | https://msdn.microsoft.com/fr-fr/library/2093ets1.aspx | 09:40.11 |
| | tor8 according to doc, _mkgmtime is the same than _mkgmtime64, unless _USE_32BIT_TIME_T is used | 09:41.01 |
| | so _mkgmtime should be sufficient | 09:41.16 |
| | checking | 09:41.19 |
| | with _mkgmtime64 explicitely | 09:41.53 |
| | strange, it seems that there is a missing link flag | 09:42.36 |
| tor8 | is mkgmtime not in the libc? | 09:43.07 |
| | they could just be missing from MSYS; but it may have the corresponding posix gmtime function instead | 09:44.16 |
| | in which case the top #define ought to be _MSC_VER instead of _WIN32 | 09:44.29 |
| | bah, I'm confusing timegm with gmtime, sorry | 09:45.16 |
| vtorri | i do not understand what the problem can be | 09:55.58 |
| tor8 | vtorri: try this for me: | 09:56.07 |
| | git add remote tor git://git.ghostscript.com/user/tor/mupdf.git | 09:56.13 |
| | git remote update tor | 09:56.20 |
| | git checkout tor/win32 | 09:56.24 |
| paulgardiner | tor8: I've discovered what was causing the glitching in muso. It was being overwhelmed with updates. Of course, it should be able to handle any number of updates, so that is a bug, but the sudden jump in the number that mupdf is producing is also worrying. | 09:56.32 |
| tor8 | paulgardiner: well, I did tell you (but it probably scrolled past in the long discussion) that commit "4b3a206d1 Load most annotations, even if they are missing appearances." fixes a bug that causes too many updates being triggered | 09:57.46 |
| | are you using that commit, and it's still triggering too many updates? | 09:58.08 |
| paulgardiner | I just tested at the end of tor/master | 09:58.23 |
| tor8 | and you still see a problem with too many updates? | 09:59.03 |
| | in pdf_update_annot I added a second guard if (annot->ap != n) to avoid triggering an update on every time through the function | 09:59.46 |
| | I thought that should have been enough. are you *positive* that you are resetting annot->has_new_ap=0 after taking on the update? | 10:00.11 |
| | or are you resetting this only after the update thread has acted on it, so it spews out more updates while the first one is in the queue? | 10:00.43 |
| paulgardiner | Before 9f8e07247, tapping on alternative check boxs, no updates: 1,2,2,2,2,2 | 10:01.15 |
| | Just after: 123,123,123,123 | 10:01.32 |
| | tor/maser: 109,110,110,110 | 10:01.46 |
| tor8 | paulgardiner: what are the numbers? | 10:02.01 |
| paulgardiner | How many annotations reported changed | 10:02.14 |
| | I have some recollection, back from when I worked on this, that it wasn't uncommon for a widget's ap to be changed and then changed back. I don't know if that's relevant | 10:03.58 |
| tor8 | paulgardiner: that *sounds* like you're not resetting has_new_ap? | 10:04.13 |
| | I just tried with mupdf-x11 | 10:04.23 |
| vtorri | tor8 git add remote etc... does not work | 10:04.24 |
| tor8 | with tor/master, adding a printf where annot->has_new_ap = 1 is set | 10:04.46 |
| | at launch, I get about a hundred updated annots (first time through) | 10:04.57 |
| paulgardiner | for (pdf_annot *annot = pdf_first_annot(ctx, page);annot;annot = pdf_next_annot(ctx, annot)) | 10:05.12 |
| | { | 10:05.14 |
| | if (annot->has_new_ap) | 10:05.15 |
| | { | 10:05.17 |
| tor8 | then I get one two updates when clicking the checkboxes | 10:05.17 |
| paulgardiner | fz_rect rect; | 10:05.18 |
| | fz_bound_annot(ctx, (fz_annot *)annot, &rect); | 10:05.20 |
| | [updateRects addObject:[NSValue valueWithCGRect:rect_from_fz(rect)]]; | 10:05.21 |
| | annot->has_new_ap = 0; | 10:05.23 |
| | } | 10:05.24 |
| tor8 | one for the 'hot' state, and one for the new state | 10:05.25 |
| paulgardiner | } | 10:05.26 |
| tor8 | printf("annot %d updated\n", pdf_to_num(ctx, annot->obj)); in pdf_update_annot just after the has_new_ap = 1 line | 10:06.18 |
| vtorri | tor8 : fatal: le chemin 'remote' ne correspond à aucun fichier (means mor eor less : the'remote' path does not correspond to any file) | 10:06.27 |
| tor8 | paulgardiner: pdfapp_updatepage() in platform/x11/pdfapp.c has pretty much the same logic | 10:06.55 |
| | vtorri: sorry, make that "git remote add tor ..." | 10:08.46 |
| paulgardiner | tor8: I'm calling pdf_update_page just before that loop. Should I be doing so? | 10:09.29 |
| tor8 | paulgardiner: yes. mupdf-x11 calls pdf_udpate_page() then recreates the annotationslist, then runs through the same loop and redraws the dirty areas | 10:10.28 |
| | pdf_update_page just loops through all annots calling pdf_update_annot | 10:11.04 |
| | which takes care of swapping in the correct 'ap' based on the current state and event hotness, and sets has_new_ap | 10:11.25 |
| | or recreating the ap if the underlying annotation properties have been edited | 10:11.37 |
| | the first time you run through this loop, *all* annotations will be considered changed | 10:12.37 |
| paulgardiner | Okay. I guess I'm screwing up somewhere. Not sure how, seeing as the only change outside of mpudf is to test and set the flag rather than use the old calls. | 10:12.43 |
| tor8 | not sure if that could be causing you problems? | 10:12.44 |
| | I guess you'll have to either add a printf("annot %d updated\n", pdf_to_num(ctx, annot->obj)); and see if that triggers in an unexpected place, or step through the debugger setting breakpoints on that line to see where the has_new_ap=1 is getting set unexpectedly | 10:13.39 |
| | paulgardiner: if you want I could take a quick look at your code | 10:21.03 |
| paulgardiner | Thanks. Let me investigate a little further, and if I turn up nothing, I'll take you up on the offer. | 10:23.02 |
| malc_ | tor8: is there some css way to convince html machinery of mupdf to not break pages? | 10:24.07 |
| paulgardiner | Actually, if you have the time, it can't hurt. Is it easiest if I just email the one file, or do you have a checked out smartoffice? | 10:24.20 |
| tor8 | paulgardiner: I have something with the remote git@artifex.githost.io:paul/sot.git | 10:25.13 |
| paulgardiner | Okay. epage/platform/ios/smart-office-nui/sodk/MuPDFDKLib.m | 10:27.23 |
| tor8 | paulgardiner: on commit 4f786422508? | 10:27.50 |
| | that still looks to be using the old pdf_clean_annot function | 10:29.07 |
| paulgardiner | current master should be up to date | 10:29.41 |
| tor8 | yeah, I see the code now | 10:30.28 |
| vtorri | tor8 i have to go, will try later | 10:32.27 |
| | i'll keep you informed | 10:32.31 |
| | bbl | 10:32.33 |
| paulgardiner | tor8: perhaps I'm recreating the fzpage and hence getting the first-pass case every time | 10:36.28 |
| malc_ | tor8: really? no way? | 10:36.45 |
| tor8 | malc_: sorry, what do you mean "not break pages"? | 10:37.17 |
| | you mean to render an infinitely long page? | 10:37.28 |
| malc_ | tor8: yeah | 10:37.35 |
| tor8 | mupdf's epub/html layout takes the page size as an input parameter; nothing in the CSS or HTML can affect the page size | 10:38.23 |
| | you could pass MAX_INT to the page height, but that would be awkward to render :) | 10:38.45 |
| malc_ | tor8: for mupdf tools maybe.. mine doesn't care really :) | 10:39.36 |
| | tor8: web is full of @media... references when i tried to ask it yesterday, but mupdf has no support for that | 10:40.13 |
| tor8 | malc_: if you don't mind getting your hands dirty with some internal guts, I could point you to where you'd need to dig | 10:40.43 |
| | malc_: both the html and epub document types use a fz_html struct to hold the html layout and operate on | 10:41.36 |
| malc_ | tor8: sure.. [i have setup emacs to make something non-horrible with tabs in mupdf yesterday] | 10:41.38 |
| tor8 | the epub just chains them together with a page break between | 10:41.46 |
| | the fz_html has a page_h field which is set when doing a layout, to get page breaks at good places so we don't break in the middle of a text line or image | 10:42.39 |
| | after the layout, the results are in the fz_html.root object | 10:43.06 |
| | which has a 'h' field, which is the resulting total height of the html layout | 10:43.19 |
| | and then all the html/epub document handlers do is provide a page sized window view of the long layout | 10:43.35 |
| | so what you could do is layout for an infinite page size, and then look at the height of the long layout and set the page height to that before rendering | 10:44.16 |
| malc_ | tor8: what would happen if h is not set at all? | 10:44.51 |
| tor8 | or just copy html-doc.c to infinite-html-doc.c and skip the whole pagination logic | 10:44.52 |
| | malc_: there is some stuff in the html layout that needs the page_h set to something reasonable to work | 10:45.30 |
| malc_ | gotcha | 10:45.38 |
| tor8 | but I think changing those to cope with page_h==0 and just ignore pagination would be easy | 10:45.46 |
| paulgardiner | tor8: I see one difference. The x11 version is rendering the update rectangles and then resetting has_new_ap. muso is collecting the rectangles while resetting the flag and doing all the rendering later. Perhaps rendering is setting the flag. | 10:46.13 |
| tor8 | paulgardiner: the flag is only set in 2 places in the code: when creating a new appearance stream, and in pdf_update_annot when it detects annot->ap having changed | 10:47.29 |
| paulgardiner | I'll add in a some debugging as you suggested | 10:47.54 |
| tor8 | malc_: flush_line does some fiddling if the line to layout is taller than would fit to move it to the top of the next page's area | 10:49.02 |
| | and layout_block_page_break would obviously need to be tweaked | 10:49.26 |
| | measure_image has some code to downsize images so they are never larger than one page | 10:50.13 |
| | but other than that I see no road blocks | 10:50.22 |
| malc_ | tor8: tack. will give it try | 10:53.08 |
| tor8 | I might be able to cobble something together which if page_h==0 will auto-size each epub chapter/html document to the full height | 10:54.09 |
| malc_ | that'd be great | 10:56.44 |
| | one can always side-step the issue by just using princexml, but... that feels dirty | 10:57.20 |
| tor8 | malc_: I think it may be a trivial change actually | 10:59.59 |
| | give me a couple of minutes | 11:00.05 |
| malc_ | you have 20 :) need to get some breakfast into the system | 11:00.29 |
| tor8 | malc_: try the commit on tor/master | 11:05.06 |
| | set the layout_h to 0 and then all html documents and individual epub chapters should appear as one page | 11:06.13 |
| | one very tall page | 11:06.18 |
| malc_ | tor8: where/when do i have to set it? | 11:09.44 |
| tor8 | in the fz_layout_document call | 11:10.23 |
| | which you should call just after loading the document, before counting how many pages there are | 11:10.35 |
| malc_ | tor8: i don't call it at all currently :) lemme fix that | 11:10.57 |
| tor8 | if you don't call it, it will be called implicitly with some default values | 11:11.24 |
| | the default is 450x600@12 | 11:12.23 |
| | the defines at the top of source/fitz/document.c | 11:12.36 |
| malc_ | tor8: perfect! tack som fan | 11:14.47 |
| tor8 | malc_: that was easier than I expected :) | 11:18.44 |
| malc_ | tor8: :) | 11:22.02 |
| | tor8: it's all because your coding typeface no longer distracts you :) | 11:22.24 |
| vtorri | tor8 : build/release/libmupdf.a(pdf-annot-edit.o):pdf-annot-edit.c:(.text$pdf_annot_modification_date+0x2b0): undefined reference to `timegm' | 11:37.36 |
| paulgardiner | tor8: most of the settings to 1 of has_new_ap are due to entering pdf_update_annot with annot->ap == NULL | 11:53.56 |
| tor8 | paulgardiner: hm, I wonder what could be setting annot->ap back to NULL | 12:22.20 |
| | vtorri: okay, so I guess you'll need to figure out why mktimegm32 doesn't work on msys2... | 12:22.54 |
| paulgardiner | I wondered that too and couldn't find where | 12:24.12 |
| Hufokus | Hello! I obtain texts from pdf using fz_new_stext_page_from_page. But I get "overstructured" text, like it may include a subtitle of an article into the plain text bounds. I can further parse stext_blocks and split it into lines and spans, but may be there is a simplier way? May be there is an option which I can pass to stext_device that say not to merge spans\lines into blocks? | 12:31.49 |
| fredross-perry | tor8 - let me know when the new annotation code gets reviewed and pushed, thanks. | 12:33.30 |
| paulgardiner | tor8: The proliferation of updates is due to my recycling of page objects on each render, so I keep hitting the initial case. | 13:31.14 |
| tor8 | paulgardiner: right, that makes sense since you're loading new pdf_annot objects along with each page | 13:31.40 |
| paulgardiner | It's not easy for me to move away from doing that right now. What's the best way to preload the ap's | 13:32.45 |
| tor8 | paulgardiner: the old code abuse the obj->dirty flag for tracking some of this info (and also other things, which caused other problems), but did let you get away with that | 13:33.02 |
| | paulgardiner: we could set has_new_ap = 0 when we load the annotation | 13:33.16 |
| | but this will not help you, I think | 13:33.37 |
| | the information that it has updated will not be around if you don't reuse the pdf_annot object | 13:33.51 |
| | unless you ignore the has_new_ap and look at and cache the pdf_to_num object number of the annot->obj in your array of annots | 13:34.39 |
| | but then you'll run into problems when annot->obj *contents* are recreated if you edit an annotation | 13:35.20 |
| | paulgardiner: a pdf_page object is very lightweight. I think you could safely just hold them all in an array. | 13:35.51 |
| | load it once and just hold on to it forever | 13:36.15 |
| paulgardiner | has_new_ap flag is working fine for to discover the side effects of pdf_pass_event. It is only the fact that the ap's aren't present on page load | 13:36.41 |
| | that causes me problems | 13:36.54 |
| tor8 | paulgardiner: you could call pdf_update_page when you load the page | 13:37.14 |
| | but you said you recreate the page each render, so how does that work with the pdf_pass_event? | 13:37.36 |
| paulgardiner | That's what I was wondering. But I'll also need to reset all the flags I guess? | 13:38.07 |
| | I don't render in the loop that iterates through the annots | 13:38.48 |
| tor8 | paulgardiner: yeah. but that would be painting yourself into a corner and running into further issues as we revise this in the future | 13:38.51 |
| paulgardiner | I just collect the rects | 13:38.53 |
| tor8 | it would be really good if you could fix it to keep the pdf_page around | 13:39.01 |
| | right, so you reload the page a second time for rendering? have two instances of the pdf_page object live at once? | 13:39.30 |
| | I mean you have two pdf_page instances loaded for the same page number at once? | 13:39.46 |
| paulgardiner | At times I do | 13:39.56 |
| | I can avoid that but I don't think I have the time just now. I should be working on something entirely different | 13:43.10 |
| | ... well not entirely - muso on windows | 13:43.30 |
| | Is it desirable that has_new_ap is always true on first enumeration? | 13:47.06 |
| | That looks to fix it at least | 13:56.12 |
| tor8 | paulgardiner: possibly not; but it would mean changing a bit and 'preloading' the annot->ap when loading the annot | 13:57.20 |
| paulgardiner | I think I'll need a work around for that even when I ensure I have just the one page object because I wont want to trigger multiple updates even on the first tap. | 13:58.12 |
| tor8 | paulgardiner: top commit on tor/master should fix that | 14:02.27 |
| paulgardiner | Magic | 14:02.34 |
| tor8 | we do automatically call pdf_update_annot to make sure we have an 'ap'. | 14:03.22 |
| | resetting has_new_ap to zero there makes a lot of sense | 14:03.31 |
| Hufokus | Hello guys. Is it a way to tell stext device not to merge spans into lines and stext_blocks? It is said that structuring uses some heuristics, is it a way to tell not to? Just to put span into stext_block | 14:03.58 |
| tor8 | Hufokus: which version of mupdf are you using? | 14:08.41 |
| Hufokus | tor8: 1.11 | 14:11.02 |
| tor8 | Hufokus: right. so the stext structure changed (was simplified) in 1.12 | 14:12.07 |
| | Hufokus: it now only has blocks and lines | 14:12.46 |
| sebras | tor8: I have reviewed up to "Fix 699026: Create missing font resource." | 14:14.29 |
| Hufokus | tor8: so lines are equal to former spans? | 14:15.06 |
| tor8 | Hufokus: we got rid of some of the more troublesome and inaccurate heuristics | 14:16.11 |
| | former spans are now lines, yes | 14:16.23 |
| | blocks correspond to paragraphs, and each line is a line of text in that paragraph | 14:16.42 |
| | you can safely ignore the 'block' level if you just want to look at the lines of text | 14:17.09 |
| paulgardiner | All fixed. Thanks for that Tor. | 14:22.01 |
| tor8 | sebras: thanks. | 14:24.44 |
| | sebras: including or excluding "Fix 699027: Create missing font resource."? | 14:25.18 |
| sebras | tor8: in "Load most annotations, even if they are missing appearances." I get the most of the changes, but that has_new_ap confuses me. | 14:27.18 |
| | tor8: including. | 14:27.23 |
| tor8 | sebras: has_new_ap is intended to be set when the annot->ap pointer either changes or what it points to has been updated | 14:28.15 |
| | so that the client can tell whether it needs to redraw the annotation or not | 14:28.30 |
| | if the annot->obj/AS state changes so we change the current active AP to say the 'down' appearance we want to set the has_new_ap flag | 14:29.50 |
| | likewise if we edit an annotation and the underlying AP stream changes | 14:30.09 |
| Hufokus | fz_stext_sheet is removed from 1.12? What replaced it with? Also,are there anywhere the changenotes 1.11 -> 1.12? | 14:51.41 |
| tor8 | Hufokus: removed completely. not replaced. | 14:56.42 |
| | the CHANGES file has the main changes, for the rest you'll need to look at the git log. | 14:57.04 |
| Hufokus | tor8: fonts and so are now stored in stext_lines, right? | 15:00.34 |
| vtorri | tor8 : ok, i'll try to find what the problem is | 15:06.10 |
| sebras | tor8: OK. | 15:41.07 |
| | tor8: "Load most annotations, even if they are missing appearances." also LGTM | 15:41.12 |
| | tor8: oh! I like "Add phony target to java makefile so it properly rebuilds the native lib." | 15:41.51 |
| | tor8: in "Auto-size HTML layout if layout page height is 0." why do we need to check max_w > 0 in measure_image()? I'm guessing this if out of symmetry? | 15:49.07 |
| | tor8: or can max_w ever be zero? perhaps if it fills the entire width or is wider than the page width..? | 15:49.58 |
| | tor8: would it be smart to squahs "Ensure has_new_ap is 0 when first loaded." and "Load most annotations, even if they are missing appearances." | 15:53.18 |
| | ? | 15:53.21 |
| | they seem to be fiddling with has_new_ap both. | 15:53.27 |
| | other than that I'm happy. | 15:53.42 |
| tor8 | sebras: max_w is just me being paranoid | 16:30.19 |
| | and it looks more consistent | 16:30.25 |
| | sebras: yeah, I'll squash them together | 16:30.48 |
| sebras | tor8: ok, then LGTM. | 16:31.17 |
| velix | tor8: hi :D | 17:00.59 |
| sebras | tor8: makeencoding.py shoudl not be in the Windows define commit at the top of tor/master. | 17:16.28 |
| vtorri | tor8 : i have found the issue : i used a too old gcc (gcc 4.8) and mkgmtime has been introduced in gcc 4.9... | 17:17.07 |
| | (for _mkgmtime) | 17:17.21 |
| | tor8 with gcc 7.2 : build/release/platform/x11/pdfapp.o:pdfapp.c:(.text$pdfapp_onmouse+0x9df): undefined reference to `pdf_check_signature' | 17:22.43 |
| Hufokus | How to force fz_stext_device to take font face/styles into account when merging spans/lines? Or should I do it myself? | 19:48.49 |
| velix | Is it possible to only compile mutools, not mupdf? gl is making problems here. | 21:34.42 |
| | Seems like you can't build mutools in cygwin. | 22:25.15 |
| | thirdparty/harfbuzz/src/hb-common.cc:222:37: error: 'strdup' was not declared in this scope | 22:25.33 |
| | I've lost 3 days with this now. | 22:36.00 |
| | I'm giving up. This really takes too long. | 22:51.52 |
| tor8 | velix: Yes, you can build only the tools. It says exactly how to do it in the documentation. https://mupdf.com/docs/building.html | 23:07.14 |
| | velix: cygwin is not officially supported. for windows you should use MSVC, or just use the linux subsystem in windows 10... | 23:08.04 |
| velix | tor8: It doesn't recognize cygwin as Linux, I thinl. | 23:08.05 |
| | tor8: Hmm okay. Then I have to wait until the next release :( | 23:08.17 |
| tor8 | make HAVE_GLUT=no HAVE_X11=no | 23:08.36 |
| velix | There are harfbuzz and the other libs in cygwin. Can't understand, why cygwin breaks :D | 23:08.36 |
| | tor8: harfbuzz has a problem | 23:08.47 |
| tor8 | or just "make tools" | 23:08.48 |
| velix | tor8: thirdparty/harfbuzz/src/hb-common.cc:222:37: error: 'strdup' was not declared in this scope | 23:08.52 |
| tor8 | C++ is always a problem. | 23:08.58 |
| velix | I see :( | 23:09.19 |
| tor8 | why can't you use MSVC? | 23:09.33 |
| | or MSYS | 23:09.37 |
| velix | Don't want to mess with my clean system. | 23:09.42 |
| | I've never had any problems building anything in cygwin ;) | 23:09.49 |
| tor8 | I've never had anything *but* problems with cygwin... | 23:10.06 |
| velix | Even ffmpeg worked. | 23:10.07 |
| | hehe :D | 23:10.11 |
| | I can install mingw in cygwin. Let's try. | 23:10.26 |
| tor8 | Unfortunately, building without harfbuzz is not really supported. | 23:10.42 |
| velix | Oh, now it breaks at a different place, 1 sec | 23:10.56 |
| tor8 | and I have no idea why cygwin's C++ compiler would complain about strdup | 23:11.11 |
| velix | "output file build/release/scripts/namedump.exe: Permission denied" ... interesting. It detects Windows again somehow. | 23:11.24 |
| | let's force the OS to Linux | 23:11.34 |
| tor8 | velix: have you told the compiler to be extra strict or something? | 23:11.44 |
| velix | nope. | 23:11.48 |
| | tor8: Who's building the official nightlies? Would be nice to have GS & MuTools binaries once a week or something ;) | 23:12.37 |
| tor8 | because you should only be getting the strdup error if you ask for strict/pedantic | 23:12.57 |
| velix | ok, let me try to find and remove it. | 23:13.14 |
| | Oh: "Add flags required for Harfbuzz because of missing strdup" | 23:13.30 |
| | CFLAGS+= -U__STRICT_ANSI__ | 23:13.41 |
| tor8 | velix: you could try adding '-std=gnu++0x' to the $(CXX_CMD) line for building harfbuzz in Makethird | 23:16.53 |
| velix | tor8: I'll try | 23:17.01 |
| tor8 | iinstead of -std=c++0x | 23:17.05 |
| | --std=gnu++0x | 23:17.25 |
| | hm, is it one or two dashes? I can't remember. | 23:17.49 |
| | anyway, try that. | 23:17.51 |
| velix | 2 | 23:17.55 |
| | --std=c++0x | 23:18.05 |
| tor8 | yeah. change that to gnu++0x and maybe that will work better. | 23:18.22 |
| velix | works as it seems | 23:19.13 |
| | LINK build/release/scripts/namedump.exe makes trouble again: Permission denied | 23:20.00 |
| | Why does it build .EXE ? | 23:20.12 |
| tor8 | it needs to build some programs to generate bits of source code as part of the build system | 23:34.19 |
| | velix: "Permission denied" certainly sounds like a cygwin problem | 23:34.59 |
| velix | So the EXE files are linux binaries? | 23:41.43 |
| | oh, he's gone. | 23:41.52 |
| | Forward 1 day (to 2018/03/20)>>> | |
Log of #mupdf at irc.freenode.net.