| | <<<Back 1 day (to 2016/10/17) | 20161018 |
| Tyr | Hi | 06:38.30 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 06:38.30 |
| Tyr | I get problems with accents when executing this command : http://pastebin.com/0KWZXvL8 | 06:39.00 |
| chrisl | I have a feeling that's not the simplest command line required to illustrate the problem | 06:41.35 |
| | Tyr: it's hard to be sure without seeing the PDF, but I'm going to guess that it doesn't have all the fonts embedded, and what you're seeing is due to font substitution happening. And note that most of that command line is having *no* effect at all. | 06:58.14 |
| | Tyr: although, I'd be tempted to try without the -dGridFitTT=2 option | 07:00.56 |
| adfg | hi guys | 09:49.12 |
| | i have a quick question, i'm trying to embed fonts into an existing pdf file using ghsotscript | 09:49.30 |
| | 'gs ' + '-o' + os.path.join(input_path, output_path) + '-sDEVICE=pdfwrite '+ '-dEmbedAllFonts=true '+ '-dSubsetFonts=true '+ os.path.join(input_path, output_path) | 09:49.44 |
| | that is the command i'm using, but apparently the fonts are not embedded in the result | 09:50.04 |
| | Can't find (or can't open) font file /usr/share/ghostscript/9.16/Resource/Font/RobotoCondensed-Regular. Can't find (or can't open) font file RobotoCondensed-Regular. Loading RobotoCondensed-Regular font from /usr/share/fonts/RobotoCondensed-Regular.ttf... 5646660 4142788 16539364 15167173 3 done. | 09:50.22 |
| | i get this for every font | 09:50.29 |
| | to me that looks like it tries to find the font in its own resource folder but then gets them from the system font folder successfully | 09:51.08 |
| kens | Ghostscript tries a heirarchy of locations for fonts | 09:55.15 |
| | But yes, eventually in your case it finds the font in /usr/share/fots | 09:55.35 |
| | Was there a question ? | 09:56.06 |
| adfg | okay, i just added the '-sFONTPATH=/usr/share/fonts' option, and it doesnt complain about missing fonts anymore | 09:56.26 |
| | my question is: why is the resulting pdf still without embedded fonts | 09:56.40 |
| kens | I couldn't possibly comment without seeing the original PDF file, and having a copy of the relevant font(s) | 09:57.04 |
| adfg | fonts are just plain old Google Roboto | 09:57.20 |
| | i just sent a copy to a colleague, maybe my viewer show subset embedded fonts as "not embedded" | 09:57.42 |
| kens | THough I would note that this isn't actually an intended purpose of the pdfwrite device, and that you are not embedding fotns, you are creating a beand new PDF file which has no real connection with the original, orhter than its appearance | 09:57.48 |
| adfg | that's okay | 09:57.59 |
| | i just need to make sure that it's viewable anwhere | 09:58.11 |
| | +y | 09:58.16 |
| kens | Best to make the original file with the fonts embedded then :-) | 09:58.40 |
| adfg | if you knew the steps that have gone into creating this pdf :D i built an entire pipeline | 09:58.50 |
| kens | Well, I can't really help without seeing the orignal PDF file | 09:59.18 |
| adfg | can't, since i'm filling in IDML templates with python, highcharts and phantom js, which is then rendered as pdf in scribus | 09:59.19 |
| | which apparently doesn't embed correctly... | 09:59.35 |
| | i'll upload the file if it doesn't work for my colleague | 09:59.47 |
| | https://drive.google.com/open?id=0B6O9Yls_eFx4RnFmaHRHTVk3YUk | 10:01.25 |
| | there is the file | 10:01.28 |
| | still won't show any text if the font isn't available on the respective os | 10:01.45 |
| kens | Pathetic viewer. SHould substitute fonts | 10:02.17 |
| adfg | adobe ^^ | 10:02.33 |
| | but we don't want substiturion | 10:02.51 |
| kens | Ah you have a custom encoding | 10:03.01 |
| | So almost certainly even if you were able to get the fonts embedded, all you would get would be the same as the Adobe output | 10:03.21 |
| | A smaller file would be easier to work with mind you | 10:03.54 |
| | decompressed this is a 325Mb file | 10:04.25 |
| adfg | not exactly sure what custom encoding is? | 10:04.30 |
| | brb, lunch | 10:04.38 |
| kens | custom = not standard | 10:04.45 |
| | Well font substitution looks unlikely to work, the Encoding uses glyph names which are all unicode code points | 10:06.02 |
| | And teh missing font is a TrueType | 10:06.23 |
| chrisl | Yeh, we end up with a load of "Substituting .notdef for uni0057 in the font RobotoCondensed-Regular" messages | 10:07.04 |
| kens | So basically, this isn't going to work | 10:07.30 |
| chrisl | adfg: One suggestion I've seen is to configure scribus to not subset fonts. That supposedly allows a lot more fonts/font types to be embedded. | 10:22.47 |
| | adfg: what version of Ghostscript are you using? I just tried the "current" code, and I get all the fonts embedded in the output PDF | 10:28.42 |
| kens | Me too, and the text is even readable afterwards, rather to my surprise | 10:33.11 |
| | NB I don't seem to have a RobotoCondensed-Regular font though | 10:34.55 |
| | OK found that, its a separate download | 10:38.19 |
| | So with all the fonts available locally, fontmap.GS updated to point to them and "gs -I/ghostpdl/Resource/Init -sDEVICE=pdfwrite -sOutputFile=./out.pdf generated.pdf" the resulting out.pdf file has all the fonts present and a random sampling of pages looks OK to me | 10:41.05 |
| | I do see a few non-standard .notdef glyphs | 10:41.31 |
| | rectangles with an internal X | 10:41.42 |
| | These appear to be the German accented characters | 10:42.08 |
| | So not entirely surprising, as these are probably encoded outside the standard ASCII range | 10:42.26 |
| | I don't see any prospect of improving that. I think you're going to have to make Scribus behave better | 10:43.27 |
| adfg | its ghostscript 9.0 | 10:49.28 |
| | 9.10 sry | 10:49.31 |
| | the thing with scribus is, that the scripter api that i use is somewhat deprecated and the new one doesnt work at all, since they werent able to connect it to the underlying qt5 yet | 10:51.00 |
| | i talked to the scribus guys | 10:51.04 |
| sebras | tor8: oi! | 10:51.10 |
| adfg | 9.16, not 9.10, just checked | 10:51.54 |
| chrisl | adfg: I think the font subsetting thing has been in scribus for some time, so that's worth looking into | 10:52.20 |
| tor8 | sebras: hi. | 10:52.36 |
| adfg | i can export it with all fonts subsetted and embedded if i use the GUI, but the scripter api seems to ignore all embedding parameters | 10:52.56 |
| | that's why i hoped to use this ghostscript fix as a workaround | 10:53.28 |
| chrisl | adfg: there's a setting for each font known to scribus | 10:53.41 |
| adfg | yes | 10:54.19 |
| | and there are embed and subset parameters given to the pdf object | 10:55.03 |
| | i dont know if gui settings apply to the scripter, but i can try | 10:55.22 |
| kens | What happens if you try writing it to PostScript instead ? | 10:55.25 |
| adfg | gotta find out if its even possible to write to ps in scripter | 10:58.22 |
| chrisl | adfg: Just to be clear, the font settings I'm talking about are in File->Preferences->Fonts->Available Fonts | 10:58.34 |
| kens | I'd try writing a PS file if you can, it may embed teh fonts there. | 10:58.54 |
| | Of coruse, it also may not, or nto be possible | 10:59.04 |
| maxupp | why cant anything ever be easy with pdf... | 11:00.36 |
| chrisl | maxupp: mainly because a) it's a complicated spec, b) there are some idiotically vague parts of the spec, and c) many of the authors of PDF creators don't really know what they are doing | 11:02.17 |
| maxupp | yeah that's pretty much what i figured | 11:09.32 |
| sebras | tor8: can you walk me through one thing? | 11:09.53 |
| | tor8: in pdf_load_colorspace() we call pdf_find_item() with a drop-function. | 11:10.07 |
| | tor8: why is this fz_drop_colorspace_imp() and not fz_drop_colorspace()? | 11:10.28 |
| tor8 | sebras: no idea. | 11:12.11 |
| Robin_Watts | sebras: Because pdf_find_item looks for an item with a matching drop function. | 11:13.02 |
| | i.e. it's matching on drop_imp not on drop. | 11:13.22 |
| sebras | Robin_Watts: yes, I get that. but how do they differ (from the point of view of the store)? | 11:13.47 |
| | also why do we compare the drop functions? | 11:14.04 |
| | isn't the key enough? | 11:14.16 |
| Robin_Watts | sebras: The store is a store of 'storable' things. | 11:14.20 |
| | The key property of a storable thing is that it must be ref counted. | 11:14.53 |
| | in order for it to be ref counted it must know how to be dropped when the refs reach zero. | 11:15.12 |
| | hence every storable has a ->drop. | 11:15.22 |
| maxupp | btw how come ghostscript is so much faster than image magick at converting pdf to png? | 11:15.27 |
| Robin_Watts | But all sorts of different objects can be stored. | 11:15.39 |
| kens | Magic pixie dust :-) | 11:15.46 |
| Robin_Watts | hence when we're searching for a given type, we have to match on 'drop'. | 11:16.19 |
| kens | But I was under the impression IM used GS to render PDF files | 11:16.25 |
| | So unless IM is processing the returned PNG file there should be a small overhead only | 11:16.49 |
| Robin_Watts | Is that what the dust did, I'd never been sure. | 11:16.57 |
| maxupp | when i built my ocr pipeline, gs batch processing was about 10 times faster | 11:17.06 |
| kens | Seems like a question you would have to adress to the IM people | 11:17.22 |
| maxupp | not that important, i was just curious | 11:17.35 |
| Robin_Watts | sebras: Why don't we just match on the key? Cos the exact form of the key depends on the type. | 11:17.44 |
| | some objects might have a smaller key than others. | 11:17.55 |
| kens | Robin_Watts : Magic pixie dust is great stuff, it does whatever you want, even if you don;t know what you wnat | 11:17.56 |
| sebras | Robin_Watts: right, that makes sense. | 11:18.04 |
| kens | Its just a pity it doesn't survive transport to customers | 11:18.18 |
| sebras | Robin_Watts: but I still don't understand why need to supply a drop function when looking for an object if each object in the store already points to a drop function. | 11:18.29 |
| | Robin_Watts: which it gets through FZ_INIT_STORABLE() I notice. | 11:18.43 |
| Robin_Watts | sebras: OK, you've got a store full of FOOs and BARs. | 11:19.11 |
| | I want to drop a FOO with key k. | 11:19.20 |
| | If I just try to drop any object from the store with a key that matches k, I might hit a BAR that happened to have a matching key and drop that. | 11:19.51 |
| | Bah. | 11:20.07 |
| sebras | Robin_Watts: right, so the concept of type is important. | 11:20.09 |
| Robin_Watts | Yes. | 11:20.13 |
| | I don't mean drop, I mean 'find'. | 11:20.19 |
| sebras | which is why it is supplied in teh call to fz_find_item(). | 11:20.28 |
| Robin_Watts | yes. | 11:20.33 |
| sebras | (and supposedly fz_remove_item()) | 11:20.36 |
| | yes | 11:20.39 |
| Robin_Watts | The 'drop' function is just a convenient way of identifying the type. | 11:20.53 |
| sebras | Robin_Watts: oh... so each stored object has no pointer to the type structure?! | 11:21.25 |
| Robin_Watts | sebras: What type structure? :) | 11:21.57 |
| sebras | Robin_Watts: pdf_obj_store_type e.g. | 11:22.11 |
| | Or that structure does not uniquely denote a type? | 11:22.38 |
| Robin_Watts | every stored object has just an fz_storable structure. | 11:22.52 |
| | Every item in the store has a pointer to the type, yes. | 11:24.07 |
| | items point to objects. | 11:24.48 |
| sebras | Robin_Watts: when I definitely don't get it. | 11:25.17 |
| | Robin_Watts: why can't we use the pointer to this type to determine if something is a FOO or a BAR? | 11:25.32 |
| | and then use the drop function stored in fz_storable? | 11:25.55 |
| | I can see how it makes sense to supply the type when storing, finding and removing items. to specify I only want to look through the FOO objects in the store. | 11:26.35 |
| | but I don't get why I need to supply the drop function if each of those stored objects already point to a drop function. | 11:26.55 |
| Robin_Watts | You might be right. | 11:27.00 |
| | I wonder if the store_type came later in the evolution of the store. | 11:27.21 |
| tor8 | I expect the drop function argument might precede the introduction of fz_storable | 11:27.27 |
| Robin_Watts | or the hash table. | 11:27.37 |
| sebras | right, that doesn't surprise me. | 11:27.44 |
| Robin_Watts | Try and strip it out and see if you hit a case where it's needed :) | 11:28.21 |
| | If you can remove it, great :) | 11:28.27 |
| sebras | Robin_Watts: oh... I think I see it. fz_find_imte() allos use_hash to be false. | 11:30.54 |
| | if it is, then it will iterate over all items in the store and compare their keys and their drop function. | 11:31.14 |
| tor8 | pdf_finditem and pdf_storeitem back in version 0.8 took drop/keep function pointers as arguments | 11:31.17 |
| | and that was when the store was a hashtable in the pdf_xref (today known as pdf_document) | 11:32.08 |
| | long before we introduced the fz_storable and generic store tied to a fz_context | 11:32.40 |
| | sebras: the original store was a two-part thing: a hash table and a linked list. | 11:33.25 |
| sebras | tor8: so basically the hash should be using the type and not the drop function. | 11:33.36 |
| Robin_Watts | sebras: Right, but we should still have the type structure then? | 11:33.43 |
| tor8 | a hash table for numbered objects (i.e. the key is '5 0 R') | 11:33.43 |
| | a linked list for non-numbered objects (i.e. the key is any old pdf_obj) | 11:34.02 |
| | and the dropfunc was then used as the 'type' identifier (since it used the key '5 0 R' to store a fz_font or fz_image) | 11:35.41 |
| | Robin_Watts: why do pdf_store_item and fz_store_item take a void* instead of fz_storable* for the val argument? | 11:37.04 |
| | is that my doing? :) | 11:37.08 |
| | I would have expected fz_store_item(ctx, key, &value.storable, &storetype) | 11:37.49 |
| Robin_Watts | The smart thing would be: | 11:38.09 |
| | #define fz_store_item(C, K, V, T) fz_store_item_imp(C,K, &(V).storable, T); | 11:38.50 |
| | without the ; | 11:38.54 |
| | brb | 11:39.10 |
| tor8 | sebras: fz_store_type is the type of the key not the value | 11:39.59 |
| sebras | tor8: oh. | 11:40.46 |
| | tor8: and I think I see the thing now. | 11:41.01 |
| tor8 | fz_storable_s has a drop_func which is they 'type' of the value, which ought to be enough | 11:41.09 |
| sebras | tor8: yes, but then that explains why we need to supply a drop function when looking up (or removing) things from the store. | 11:42.22 |
| | I didn't pick up on the distinction between the types of the keys and the values. | 11:42.31 |
| tor8 | yes. | 11:42.31 |
| sebras | tor8: what made me take a look is that fz_colorspace_imp() must be exported to pdf-clorspace.c | 11:43.51 |
| | because it wants to store/lookup/remove its separation colorspaces from the store. | 11:44.12 |
| | if not for this fact then fz_colorspace_drop_imp() could have been static. | 11:44.54 |
| | but this still ought to mean that fz_colorspace_drop_imp() will only ever be called with non-NULL arguments. | 11:45.20 |
| tor8 | yes, the drop_imp should never be called with NULL arguments | 11:45.45 |
| | though I see now that the fz_storable drop relies on the drop_imp to free the 'container' malloc | 11:46.08 |
| | we could clean that up to be in line with what we decided the drop/drop_imp separation should be | 11:47.05 |
| sebras | ah. | 11:49.53 |
| Robin_Watts | drop takes a lock, and calls drop_imp. | 11:50.37 |
| | It's possible that the store can't call drop as it has the lock already. | 11:51.17 |
| sebras | Robin_Watts: ? I think tor8 meant that fz_drop_storable() could, after s->drop() is called doi fz_free(ctx, s); while e.g. fz_drop_colorspace_imp() would not fz_Free(cs); | 11:56.41 |
| | i.e. similar to how the dropping of e.g. documents works. | 11:57.02 |
| maxupp | fuck, i hate doing 5 things at once. looks like the fonts thing is prio c for now | 11:59.27 |
| Robin_Watts | sebras: Oh, um, yes. | 12:03.01 |
| | The only problem with that, is that it would force any 'storable' object to have the storable entry at the start. | 12:03.25 |
| | (which is the case everywhere so far) | 12:03.39 |
| sebras | Robin_Watts: correct. | 12:03.47 |
| Robin_Watts | so, yes, I could live with that. | 12:03.58 |
| sebras | Robin_Watts: btw, tor8 and I discussed elsewhere yesterday why fz_alpha_from_gray() is needed and whether we couldn't just poke at the pixmap directly to convert from gray without alpha to alpha only. | 12:05.54 |
| | Robin_Watts: but, at least I, was unsure of whether to copy created by fz_alpha_from_gray() is necessary somewhere..? | 12:06.26 |
| Robin_Watts | In fz_draw_end_mask, the code there allows for not dropping the source alpha. | 12:07.50 |
| | Now, that may well be overkill, and it might always drop the alpha. | 12:08.12 |
| | I would be all in favour of changing fz_alpha_from_gray from being an allocate/copy/free thing to being something that just changes the pixmap type. | 12:09.19 |
| | but to do that we'd need to convince ourselves that fz_draw_end_mask is safe like that (and it really ought to be). | 12:09.43 |
| | I'd start by clusterpushing a crash in the case where state[1].dest == state[0].dest | 12:10.28 |
| | Again the structure of the code is a historical hangover. | 12:11.00 |
| sebras | Robin_Watts: yeah, sorry for running in to those a lot lately. :) | 12:12.06 |
| Robin_Watts | sebras: No, if it simplifies and improves the code, it's a good thing. | 12:12.32 |
| sebras | Robin_Watts: should that abort be present only for end_mask? | 12:24.55 |
| Robin_Watts | That's the only place I could see us calling alpha_to_gray without it being a simple drop afterwards. | 12:25.29 |
| sebras | tor8: a few patches over at sebras/master being clustered as we type. | 12:57.10 |
| tib0 | hi, i'm trying to build mupdf for android platform and i've got a error : Could not find incbin file 'resources/fonts/sil/CharisSIL-B.cff'. can someone help me ? should i took a previous version ? | 13:23.15 |
| kens | tib0 : you may have to wait a few minutes for a reply | 13:24.27 |
| tib0 | ok | 13:24.43 |
| kens | Sounds like the 'generated' files have not been created, and I'm 'fairly' sure you do that on the host | 13:24.52 |
| | Did you do that step ? | 13:24.57 |
| | tib0 did you see item 10 in MuPDF/platform/android/viewer/readme.txt ? | 13:27.36 |
| tib0 | i did a make generate | 13:29.48 |
| kens | OK and then you cpoied the generated files to the right place on your android build ? | 13:30.20 |
| | s /cpoied/copied/ | 13:30.30 |
| tib0 | i didn't copy it | 13:31.52 |
| kens | Well I think you will have to copy the contents of generated from the host platform to the android build's 'generated' folder. | 13:32.28 |
| | But I'm getting out of my depth here, so I'm going to bow out and wait fomr someone who really knows what they are talking about. I've never built MuPDF for Android | 13:33.08 |
| tib0 | into platform/android folder ? | 13:33.33 |
| kens | I woudl assume so yes | 13:33.48 |
| | But I am no expert on this | 13:33.56 |
| tib0 | it doesn't work. thwx you for your help | 13:34.29 |
| kens | Stick around someone who knows more will come along | 13:36.13 |
| tib0 | ok | 13:36.25 |
| sebras | tib0: you ought to have a folder called generated in the top build directory, can you find CharisSIL-B.c in there? | 13:41.21 |
| | tib0: if not, then the generation is the problematic step. | 13:41.36 |
| | tor8: Robin_Watts: ok, so my patches at sebras/master cluster fine now. | 13:43.23 |
| | tor8: Robin_Watts: that leaves me with a commit listing a number of possible leaks that I need to look into. | 13:43.57 |
| Robin_Watts | kens, tib0: No copying required. As long as generated has the files in that's fine. | 13:51.46 |
| kens | said I wa no expert :) | 13:53.03 |
| Robin_Watts | sebras: Hmm. The "not checking NULL before calling fz_drop" commit... | 13:54.09 |
| | There are times when it *is* worth checking NULL before calling. | 13:54.21 |
| sebras | Robin_Watts: yes, in loops, but not otherwise. | 13:54.42 |
| Robin_Watts | exactly. | 13:54.50 |
| sebras | Robin_Watts: did I accidentally get one of those? | 13:54.54 |
| Robin_Watts | so fz_drop_font ? | 13:54.58 |
| | and free_resources | 13:55.07 |
| | fz_fin_cached_color_converter ? | 13:55.36 |
| sebras | pdf_load_shading_dict | 13:56.07 |
| | noted. | 13:56.30 |
| Robin_Watts | I'm inclined to think that pdf_load_shading_dict is not performance critical. | 13:57.14 |
| tib0 | i tried again and it works if i let APP_ABI := armeabi-v7a, and it crashed with APP_ABI := all | 13:57.25 |
| Robin_Watts | sebras: In the last commit, I am confused by orig_pixmap in fz_draw_fill_image | 14:01.14 |
| sebras | Robin_Watts: so... pixmap is a variable pointing to a pixmap that we are working on. | 14:03.48 |
| | it might point to orig_pixmap or scaled | 14:03.54 |
| | both which are pixmaps that are allocated. | 14:04.07 |
| | therefore we should free orig_pixmap and scaled. | 14:04.21 |
| | and now that we allow fz_new_converted_pixmap() to overwrite the original pixmap pointer (because it also consumes it) we need to accordingly update orig_pixmap. | 14:04.53 |
| | does that make sense? | 14:04.57 |
| Robin_Watts | ok. | 14:04.58 |
| | Can we rename orig_pixmap to drop_pixmap? | 14:05.11 |
| | cos it's not the original pixmap anymore., | 14:05.19 |
| | jpx_read_image looks wrong to me. | 14:06.09 |
| | If we free state->pix in the catch case, then then cleanup code will free it again. | 14:06.28 |
| | state->pix = NULL; would solve that, but why not leave it for the cleanup? | 14:06.56 |
| | fz_new_converted_pixmap is slightly inconsistent. | 14:08.50 |
| | If I call fz_new_convert_pixmap and pass in pix, am I guaranteed that pix is destroyed? | 14:09.42 |
| | The current implementation does not guarantee that. If the fz_new_pixmap fails, then pix remains in existence. | 14:11.09 |
| | BUT if that passes, and the fz_convert_pixmap fails, then pix is dropped. How can the caller tell the difference? | 14:11.31 |
| | If you amend the code so that the fz_new_pixmap failing ALSO drops pix, then this causes problems with some of the callers. | 14:12.21 |
| | jpx_read_image for example calls: state->pix = fz_new_converted_pixmap(ctx, state->pix, fz_device_rgb(ctx), 0); | 14:13.17 |
| | If that fails state->pix is freed, but state->pix still points to it. | 14:13.35 |
| | We need to do: pixmap = state->pix; state->pix = NULL; state->pix = fz_new_converted_pixmap(ctx, pixmap, ....); | 14:14.08 |
| | There should be a clear and unambiguous statement that fz_convert_pixmap *always* frees the input pixmap. | 14:14.36 |
| | That is the only caller where I can see that problem. | 14:15.24 |
| | Other than those points it all looks good. | 14:15.36 |
| jhan | Hello all.. | 17:57.11 |
| | i am trying digital signature on pdf for ios | 17:57.53 |
| | is mudpdf will support that ? | 17:58.35 |
| | i have a plan to do my educational project on this can any one suggest me how to do.. | 17:59.23 |
| Robin_Watts | jhan: Digital signatures on MuPDF are an incomplete area. | 18:21.22 |
| | What did you have in mind to do with them ? | 18:21.38 |
| jhan | i have plan to develop one ios application where user can sign digitally. One of my senior did similar type project by using podofo. | 18:27.12 |
| | so that we can provide paper less signature to users | 18:27.33 |
| | i downloaded the code from net and everything working fine.. | 18:28.37 |
| | just i want to know the steps to achieve..can we please tell me robin | 18:30.39 |
| Robin_Watts | Are you an experienced C coder? | 18:31.19 |
| jhan | don't have more idea on that @Robin.. | 18:32.36 |
| Robin_Watts | If you aren't comfortable coding in C, then this is not a project for you. | 18:32.56 |
| jhan | Yes i am comfortable to understand c, but depth level | 18:33.44 |
| | i have studied the adobe PKI concept | 18:34.34 |
| | and i have good idea on signature process | 18:35.02 |
| | but i don't know how to use mupdf api's to achive this | 18:35.27 |
| | i just want to see simple code for signature process, rest of the things i can mange. is it possible to share @Robin | 18:37.42 |
| Robin_Watts | I have no such "simple code". | 18:37.55 |
| | I don't think anyone does. | 18:38.01 |
| | The android viewer has code for checking signatures. | 18:38.14 |
| jhan | Please Robin help me | 18:38.16 |
| | yes i saw that.. | 18:38.29 |
| Robin_Watts | No one has done signing. | 18:38.36 |
| | So there is no API for it. | 18:38.44 |
| | To do so would require changes within MuPDF. | 18:39.02 |
| jhan | i don't want to checking signature i just want embed signature into pdf | 18:39.04 |
| | i generated the signature by using openssl open source library | 18:39.45 |
| Robin_Watts | (or at least would require you going deeper than the standard APIs) | 18:39.48 |
| | If you *do* want to do this project, then I would advise doing it as a simple command line tool first (musign in.pdf signature out.pdf) | 18:41.12 |
| | Then, once you have that working, then consider building an ios front end. | 18:41.42 |
| jhan | Hi robin if you don't mine can you please elaborate little.. | 18:46.18 |
| | [00:11] <+Robin_Watts> If you *do* want to do this project, then I would advise doing it as a simple command line tool first (musign in.pdf signature out.pdf) | 18:46.26 |
| Robin_Watts | Don't code it in ios. | 18:46.40 |
| | There are 2 parts to the project, right? | 18:46.55 |
| | The first part is doing the signing. | 18:47.04 |
| jhan | yes.. | 18:47.10 |
| Robin_Watts | The second part is writing an app with a UI to select a PDF and a signature etc. | 18:47.22 |
| jhan | Next is appearance i am right ? | 18:47.25 |
| Robin_Watts | Right. | 18:47.34 |
| | So simplify the job as much as possible. | 18:47.41 |
| | just write a simple tool that you can call from the command line to sign a given PDF. | 18:48.09 |
| | Even that is not a simple job. | 18:48.17 |
| jhan | yes its not simple :( | 18:48.38 |
| Robin_Watts | You say you've read up on the process of signing a PDF? | 18:49.40 |
| jhan | yes | 18:50.00 |
| Robin_Watts | Your memory is probably fresher than mine then. Can you describe what you need to do? | 18:50.02 |
| | oh, wait... | 18:52.17 |
| | maybe we have support for this after all... pdf_sign_signature. | 18:52.28 |
| | Ah, right, that assumes that you have a document with a signature widget in it. | 18:53.24 |
| | Then signs that widget. | 18:53.30 |
| jhan | i have setuped the project using cocoapods in ios, I just wanna sign pdf by using pkcs7 and appearance | 18:53.32 |
| Robin_Watts | jhan: So your input would be a PDF with a form in it that has a signature form field ? | 18:54.32 |
| jhan | since 2 and half month i am working on this robin.. | 18:54.32 |
| | that has no signature signature field @robin | 18:55.38 |
| | i need to create signature field first | 18:56.00 |
| Robin_Watts | Ok, so MuPDF has code to sign a PDF that already has a form with a signature form field in. | 18:56.23 |
| jhan | so we can't create signature field with mupdf ? | 18:57.01 |
| Robin_Watts | There is no code to create a signature field at the moment, no. | 18:57.19 |
| | I would imagine that it is possible to add a blank form to a document and then to add a blank signature field to that form by calling the existing MuPDF APIs. | 18:58.23 |
| | Then you can sign that. | 18:58.31 |
| | But I can't give you any existing code to tell you how to do it. | 18:58.51 |
| | First you'd call fz_document_open() to open the document. | 18:59.03 |
| | Then you'd call pdf_specifics() to get a pdf specific document handle. | 18:59.27 |
| jhan | oh thanks a lot buddy for your help.. | 19:00.29 |
| Robin_Watts | ooh, there is code for this. | 19:01.35 |
| | Call pdf_create_widget() to create a PDF_WIDGET_TYPE_SIGNATURE. | 19:01.58 |
| | Then you can call pdf_sign_signature with that. | 19:02.10 |
| jhan | pdf_widget *widget; fz_write_options opts = {0}; opts.do_incremental = 1; widget = pdf_create_widget(ctx, idoc, (pdf_page *)app->page, PDF_WIDGET_TYPE_SIGNATURE, "test1"); pdf_sign_signature(ctx, idoc, widget, "Raed.pfx", "123456"); pdf_write_document(ctx, idoc, "signed.pdf", &opts); | 19:08.12 |
| | is it enough @robin' | 19:08.40 |
| Robin_Watts | looks plausible. | 19:10.02 |
| jhan | here i want to do sign for existing.. | 19:11.18 |
| | i didn't get how to create pdfsignature filed ? | 19:11.51 |
| Robin_Watts | Sorry, I didn't understand that. | 19:12.27 |
| jhan | As you told me we can't sign on existed pdf files by using mupdf, if we want sign any pdf file it should has signature filed like (Reason,name ets).i have been searching same code..is it possible to give suggestion @robin | 19:16.14 |
| Robin_Watts | jhan: The fragment of code you gave above CREATES a signature field, and then signs it. | 19:17.00 |
| | So that *should* sign any PDF file. | 19:17.11 |
| | (i.e. you don't need to have one with an existing signature widget) | 19:17.27 |
| | I wasn't aware that we had code to create such things, so I apologise for being wrong earlier. | 19:17.58 |
| jhan | oh its ok @robin thanks | 19:18.30 |
| Tercus | hi. Is any of the mupdf devs here? Their website said they might be hanging around here | 23:10.57 |
| | Forward 1 day (to 2016/10/19)>>> | |
Log of #ghostscript at irc.freenode.net.