| | <<<Back 1 day (to 2021/01/22) | Fwd 1 day (to 2021/01/24)>>> | 20210123 |
| rpite | why is the pdf reader not able to read a 7,8,',or 'L' when I manually edit the text of the pdf with vim? | 02:43.22 |
| artifexirc-bot | <KenSharp> rpite You can't (in general) 'manually edit the text' of a PDF file. Subset re-encoded fonts mean that the text you are trying to draw may not be present in the font. Also the re-encoding may mean that even if the character is present in the font it may not be referenced by the character code you are typing. Text in a PDF file may use its own encoding, not ASCII or Unicode. | 09:08.43 |
| rpite | ah it's because it's stripped | 15:45.23 |
| | how do I find the font so I can reembed it into the pdf file | 15:45.40 |
| artifexirc-bot | <KenSharp> rpite apologies I was in another channel (and a Zoom meeting) | 16:02.39 |
| rpite | np | 16:02.50 |
| artifexirc-bot | <KenSharp> I'm afraid that finding the original font may not be sufficient. | 16:02.58 |
| rpite | why? is it because I have to change /FontFile2 to the new font file | 16:03.28 |
| artifexirc-bot | <KenSharp> Bear in mind that without seeing your PDF file I'm forced to talk in very general terms. It is possible that your case is simpler than this, but I'm covering the worst case | 16:03.39 |
| | <KenSharp> The character code you see in a 'Tj' or 'TJ' operation is just that, a code. | 16:03.58 |
| | <KenSharp> It points via an Encoding array into the font, the Encoding array maps a character code to a glyph name, then we use the name to find tyhe glyph program in the font, and draw it. | 16:04.40 |
| | <KenSharp> For subset fonts, its is common to embed the glyphs in the order thay are used, and reference them that way from the Encoding | 16:05.05 |
| rpite | ok, so adding new font messes up order | 16:05.33 |
| artifexirc-bot | <KenSharp> So 'Hello World' would have an Encoding where 1->/H, which draws the H glpyh, 2->/e which draws the 'e' glyph and so on | 16:05.41 |
| | <KenSharp> rpite, yes exactly, the font arrangement of the original font won't match that of the subset font | 16:05.58 |
| | <KenSharp> NB this is a worst case situation! | 16:06.07 |
| rpite | NB? | 16:06.24 |
| artifexirc-bot | <KenSharp> Even if you locate the original font, and its Encoding matches the subset one, replacing the font in teh PDF file would change the offsets of all the objects, so you would need top repair it aftwerwards | 16:06.50 |
| rpite | oh that | 16:07.01 |
| artifexirc-bot | <KenSharp> N = Nota Bene, Latin for 'note well' | 16:07.08 |
| | <KenSharp> Just means Note with emphasis | 16:07.22 |
| rpite | rip cli pdf editor dreams | 16:07.54 |
| artifexirc-bot | <KenSharp> Its not impossible to edit a PDF file, but it is fraught with problems, generally it's best to go back to the source file and change that, then remake the PDF | 16:08.00 |
| rpite | ok, thanks for your help | 16:09.40 |
| artifexirc-bot | <KenSharp> No problem, good luck with whatever you are doing | 16:09.55 |
| earnestly | mupdf (gl) allows the tinted "background" colour to be set with -C but this leaves the margins as whatever grey it normally is. E.g. https://0x0.st/--84.png -- is it possible to change this (in my case I'd like it the same colour as the "page") or where is it set in the source? | 23:05.25 |
| sebras | earnestly: by running mupdf-gl -I mydoc.pdf you can get it set to black. | 23:21.59 |
| earnestly | sebras: I don't mean the colour of the page itself, but the background | 23:22.59 |
| sebras | earnestly: other than that you appear to have to edit the 0.3f values in run_main_loop() in playtform/gl/gl-main.c and rebuild the project. | 23:23.00 |
| | earnestly: I got that, but -I affects both. | 23:23.10 |
| | earnestly: barring rebuilding from source that's the only way to affect it that I can see. | 23:23.34 |
| earnestly | Yeah, what the screenshot shows is inverted | 23:24.00 |
| | I don't mind faffing about with the source to see what happens | 23:24.45 |
| | Ah, there glclear is, thanks. I should have just searched for that api | 23:25.09 |
| sebras | earnestly: right, then the the call to glClearColor() is your friend. | 23:25.16 |
| | earnestly: I simply changed it to 0.7f for red and it worked fine. | 23:25.45 |
| earnestly | Yeah | 23:25.50 |
| | Thanks | 23:25.53 |
| | sebras: https://0x0.st/--8I.png (the inverted version is off, but I was mucking about and used this approach: https://0x0.st/--8l.diff ) | 23:42.58 |
| | Works though, which is nice | 23:43.03 |
| sebras | earnestly: nice. :) | 23:44.47 |
| | maybe this is impetus for ator to make this configurable from the command line. | 23:45.16 |
| earnestly | What might be nice, is if mupdf-gl stored page number in its history json file (I don't think mupdf non-gl stores history at all). That way the number could be used on the command-line (currently it appears to only store chapter and position) | 23:48.37 |
| | <<<Back 1 day (to 2021/01/22) | Forward 1 day (to 2021/01/24)>>> | |
Log of #mupdf at irc.freenode.net.
