| | <<<Back 1 day (to 2015/02/15) | 20150216 |
| jhabjan | seems there is a problem with GS and Khmer (Cambodia language) | 08:58.50 |
| | example pdf: https://www.dropbox.com/s/1zcwbas2x9cdeoc/Khmer_Cambodia_Language_Test_1.pdf?dl=0 | 08:59.14 |
| | gs output: https://www.dropbox.com/s/b7lwsgs9h429iuf/Khmer_Cambodia_Language_Test_1_GS_Output.gif?dl=0 | 08:59.37 |
| | the text in red is not rendered properly | 09:00.09 |
| chrisl | jhabjan: read this: http://bugs.ghostscript.com/show_bug.cgi?id=695832 | 09:00.12 |
| | jhabjan: I assume he didn't like our answer, so bothered you instead..... | 09:00.49 |
| kens | Yeah, I didn't see any bug there myself | 09:01.03 |
| | Its an annotation where the box supplied for the text is too small for the text | 09:01.17 |
| | SO the right edge gets truncated, a similar effect can be seen with Adobe Acrobat | 09:01.35 |
| jhabjan | ah.. seems it's a same developer | 09:02.04 |
| kens | Because Acrobat ignores the appearance stream and generates its own heuristically the result is not quite the same as ours, but nevertheless it demonstrates the real problem | 09:02.06 |
| | If I were you I'd refer him to our answer on the subjext in the bug thread | 09:02.38 |
| jhabjan | right | 09:03.49 |
| | he reported this bug also on codeplex and sent me email directly | 09:04.09 |
| | Ill refer him to your answer | 09:04.24 |
| kens | FWIW opening his file in pdf.js on dropbox exhibits what appears to me to be *exactly* the same problem as GS | 09:04.36 |
| | You could tell him to try that and see what he says | 09:05.28 |
| jhabjan | ok, no worries | 09:08.25 |
| | thanks | 09:08.30 |
| kens | Not a problem, sorry he cam e and bugged you about it.... | 09:08.41 |
| jhabjan | no problem... i'm used to it :) | 09:09.14 |
| kens | Hehe welcome to our world :-D | 09:09.26 |
| jhabjan | kens: you mentioned pdf.js, did you ever consider porting mupdf to javascript ? | 09:38.50 |
| kens | Nope. | 09:38.58 |
| | MuPDF is meant to be quick | 09:39.06 |
| jhabjan | as.. pdf.js lacks some features.. like pinch zoom | 09:39.11 |
| kens | pdf.js is also very poor at transparency, lacks transfer functions if I remember correctly, and has some other rendering problems also | 09:39.43 |
| jhabjan | when I tried to implement pinch zoom in pdf.js I found out it has a lot of memory problems | 09:40.04 |
| kens | That doesn't surprise me. | 09:40.15 |
| jhabjan | so.. what cross my mind is.. emscripten ( http://kripken.github.io/emscripten-site/ ) | 09:40.21 |
| kens | But bear in mind that I know nothing about JavaScript | 09:40.28 |
| | I think Tor has looked at that before. In any event, I'm not the right person to talk to, I just do GS :-) | 09:41.00 |
| jhabjan | no worries.. I'm just thinking loud | 09:41.36 |
| | :) | 09:41.38 |
| Robin_Watts | Morning tor8. | 10:53.03 |
| | I got the display list rework working over the weekend. | 10:53.30 |
| | There are something like 58 cluster diffs, which are all tiny rounding things. | 10:53.44 |
| tor8 | Robin_Watts: fantastic! | 10:53.47 |
| Robin_Watts | A while ago, you fixed the fz_path stuff to use separated commands and coords. | 10:54.23 |
| | cos it was better for opengl that way. | 10:54.33 |
| tor8 | oh yeah | 10:54.43 |
| Robin_Watts | I was pondering the idea of adding things like horizontal path, and vertical path to paths. | 10:55.00 |
| | urm, lines. | 10:55.16 |
| | but that would mean we wouldn't be pushing pairs of coords. | 10:55.31 |
| tor8 | ah, more subcommands? like hlineto and vlineto? | 10:55.32 |
| Robin_Watts | yeah. | 10:55.36 |
| | How badly would that break opengl (and do we care?) | 10:55.47 |
| | likewise I was pondering conic_to | 10:56.52 |
| | and possibly ones for v and y. | 10:57.06 |
| tor8 | I dunno, I rather like the simplicity of having the smallest necessary subset of commands | 10:59.59 |
| | hline and vline do make sense for squeezing memory use | 10:59.59 |
| | but currently all the commands use absolute positioning | 11:00.00 |
| | it adds complexity to all of the path consumers | 11:00.04 |
| | unless we add an iterator-like interface which emits the current subset of commands | 11:00.05 |
| Robin_Watts | Picsels stuff has a 'processPath' function that calls callback functions for each of the segment types. | 11:01.12 |
| | so we can do path compression/new types in there with no problems. | 11:01.26 |
| tor8 | I was hoping to avoid callbacks | 11:01.26 |
| | it's what freetype does as well | 11:01.36 |
| Robin_Watts | but I fear it'd be slower here. | 11:01.41 |
| | I think callbacks is a natural way to work for this stuff. | 11:02.14 |
| | If you look at path consumers, they all tend to end up calling functions anyway, I think. | 11:02.37 |
| tor8 | Robin_Watts: I think we'd be best served by preallocating the right size buffers for the cmd/coord arrays to fit a rectangle perfectly | 11:02.39 |
| | Robin_Watts: yeah | 11:03.17 |
| | that's actually true | 11:03.20 |
| | so maybe just a fz_walk_path that takes moveto/lineto/curveto/closepath function pointers | 11:03.44 |
| | then we can squeeze the data structure with hlineto and vlineto if needed | 11:04.04 |
| Robin_Watts | tor8: Well, it can take a full set of function pointers, and can translate ones that are NULL into calls to ones that aren't as required. | 11:04.20 |
| tor8 | I think that's why I've got the instinctive dislike of the current path consumer code, all it does is unpack the structure (duplicated code in all of the consumers) and call functions | 11:04.36 |
| Robin_Watts | yes, not having the path walking duplicated would be nicer. | 11:05.05 |
| tor8 | I would prefer the simplicity in the interface (maybe a conicto, but I am hard pressed to see a real use for it) | 11:05.25 |
| | any hlineto etc optimisations for pdfwrite would be trivial to do on the pdfwrite side | 11:05.56 |
| Robin_Watts | font outlines use conics | 11:06.02 |
| tor8 | which we decompose to a curveto in the font outline extraction | 11:07.10 |
| Robin_Watts | As do other graphics formats (like swf, not that I think we'll ever be doing that) | 11:07.18 |
| | indeed. We could avoid that decomposition. | 11:07.26 |
| tor8 | and probably for the SVG/XPS conic commands as well | 11:07.30 |
| | Robin_Watts: it turns the conicto into one curveto | 11:07.50 |
| Robin_Watts | The opengl stuff is not in this codebase, right? | 11:08.27 |
| tor8 | no, it's not | 11:08.34 |
| | it's rotting off to the side | 11:08.38 |
| | and if I resume it, first thing I'm going to do is rip out the dependency on the nvidia path extension | 11:08.53 |
| | but as it is, I'm going to wait and see what glNext will end up like | 11:09.25 |
| Robin_Watts | I thought the big thing about glnext was that it could be driven massively threaded. | 11:09.48 |
| tor8 | I haven't been paying a lot of attention | 11:11.11 |
| | but anything that cleans up the current mess is a welcome change | 11:11.20 |
| Robin_Watts | AIUI (from a quick read last week) Currently OpenGL can only be called from a single thread at a time. | 11:11.42 |
| tor8 | yeah. it uses threading behind the scenes in the driver pretty extensively though. | 11:12.00 |
| Robin_Watts | the idea is that the new version will allow lots of processors/threads to call it at the same time, thus unlocking vast potential speedups. | 11:12.04 |
| kens | Hmm, I can't ping bugs.ghostscript.com, can anyone else ? | 11:47.40 |
| Robin_Watts | I can. | 11:48.47 |
| kens | Must be just me then | 11:48.53 |
| Robin_Watts | 50.240.204.218 ? | 11:48.54 |
| kens | Yes, that's the IP I'm trying | 11:49.02 |
| tor8 | kens: can't load the website | 11:49.15 |
| kens | I can't load the website either, hence the ping :-( | 11:49.28 |
| tor8 | nor ping it | 11:49.30 |
| kens | OK so not just me | 11:49.38 |
| kens | feels better | 11:49.42 |
| Robin_Watts | ATS is down too :( | 12:00.34 |
| | bugs is now at marcosw's house, right? | 12:00.52 |
| | I suspect an outage. | 12:00.58 |
| kens | Umm you could be correct, let me look at the dashboard | 12:08.19 |
| | Well thatsays all Marcos' machines are up | 12:08.38 |
| | Might only be able to tell on a regression run though | 12:08.56 |
| | I almost got through to bugs just then, got a partial page | 12:09.14 |
| | And now its up... | 12:09.28 |
| henrys | holiday in the US today if you didn't see Michael's email. | 14:08.26 |
| chrisl | President's Day, IIRC...... | 14:11.09 |
| kens | THat's what my calendar says yes | 14:14.57 |
| henrys | I was getting worried about the skiing we've had a string of record high temperatures.... but it's been snowing for a couple days now. | 15:22.51 |
| kens | is pleased to hear it :-) | 15:23.12 |
| | Hmm copper mountian snow report says 5 inches in the last 24 hours, mid mountain at 54 inches, top at 59 inches, that's pretty good by my terms | 15:38.01 |
| sohail-ahmed | Though I know that this channel is for developers but I am having a missing font problem while using ghostscript, could any body help? | 16:27.14 |
| kens | Not unless you provide more information. | 16:27.26 |
| sohail-ahmed | Ty I will | 16:27.35 |
| | I am trying to extract a page 19 from a pdf document. Here is the error. http://pastebin.com/wgsc2zEc | 16:29.35 |
| kens | Yes, no error there, just a bunch of warnings | 16:29.58 |
| sohail-ahmed | thanks. I did not noticed the file. Though how can I avoid this error? | 16:30.54 |
| kens | Also (standard lecture) you are not 'extracting a page' What you are doing is executing page 19 of the original file, interpreting it to create a list of graphical primtives and creating a brand new PDF file which consists of those graphics primitives, re-assembled into a vliad PDF file | 16:30.58 |
| | There isn't an error there, its a warning. If you don't want the warning then either embed the fonts in the original PDF file or add the font to Ghostscript, or add a substitute font to Ghostscript. | 16:31.37 |
| sohail-ahmed | thanks. 'extracting' was a bad phrase. many thanks!!!! | 16:32.17 |
| kens | http://www.ghostscript.com/doc/9.15/Fonts.htm | 16:32.17 |
| Robin_Watts | sohail-ahmed: An alternative approach would be to use mutool (part of mupdf). | 16:34.05 |
| | mutool clean in.pdf out.pdf 19 | 16:34.14 |
| kens | Which genuinely will extract just the page, no reinterpreting | 16:34.32 |
| Robin_Watts | That will extract just page 19 of in.pdf | 16:34.36 |
| | mutool -ggg clean in.pdf out.pdf 19 may produce a smaller file. | 16:34.50 |
| sohail-ahmed | thanks. Isn't gs is more powerful when it come to functionality? | 16:35.12 |
| kens | Depends what you want to do | 16:35.22 |
| | Currently GS can do things MuPDF can't (in general stuff like changing colours and colour spaces) but it *always* intepretst he file, which can cause other difficulties | 16:35.52 |
| sohail-ahmed | Can I use gs to edit this pdf file which is mainly a table. So If want to add some thing to that table, would gs help? any other tool? | 16:36.44 |
| kens | GS doesn't do interaction, so no you can't use GS to edit the file. | 16:37.03 |
| sohail-ahmed | any other tool for that? | 16:37.29 |
| kens | Adobe Acrobat allows you to edit files. MuPDF has some limited ability to do so depending mostly on what you want to do | 16:37.30 |
| | Very few tools will edit PDF files, its not a simple task | 16:37.44 |
| | Adobe Illustrator is another one. | 16:37.53 |
| sohail-ahmed | but its not free!! | 16:38.01 |
| kens | No, that's because its not easy :-) | 16:38.13 |
| chrisl | mupdf on Linux doesn't do any editing | 16:38.17 |
| kens | Striclty GS isn't free either, its open source | 16:38.21 |
| Robin_Watts | sohail-ahmed: emacs. | 16:38.22 |
| sohail-ahmed | Robin_Watts: any link? | 16:38.42 |
| Robin_Watts | You can use mupdf to 'decompress' PDF files. | 16:38.45 |
| | Then you can at least make changes yourself by editing the low level PDF objects in an editor. | 16:39.19 |
| | Then you can run the files back through mupdf to fix up the file offsets etc. | 16:39.42 |
| | If you just want to make tiny tweaks to a file, then that might be a solution. | 16:40.01 |
| sohail-ahmed | Robin_Watts: did not you not just said that emacs can do it? | 16:40.10 |
| Robin_Watts | If you want something more WYSIWYG then you'll need something else. | 16:40.21 |
| | sohail-ahmed: Yes. Emacs can be used as an editor once you've decompressed the file in mupdf. | 16:40.43 |
| | but there is no simple 'load this pdf file, click here, change some text' editing solution. | 16:41.02 |
| chrisl | sohail-ahmed: You could try: http://sourceforge.net/projects/pdfedit/ - but my experience is that it's not terribly good, nor reliable | 16:41.47 |
| kens | PDF wasn't intended to be editable. SO its not an easy thing to edit | 16:41.58 |
| sohail-ahmed | chrisi, I used that on windows some years back and it was terrible. | 16:42.29 |
| chrisl | sohail-ahmed: well, as commented above, editing is not what PDF was designed for, is very, very hard to do, and practically impossible to do reliably and well. | 16:44.09 |
| sohail-ahmed | thanks every body for your time. At present, as suggested I would try to decompress pdf file mupad and see how can I add a little text to it and then recompile. | 16:46.04 |
| kens | ROFL 'we bought the full source code....and we can't fix it' :-) | 16:46.09 |
| chrisl | kens: as long as they are willing to pay...... | 16:47.00 |
| kens | Strangely I don;t see any mention of payment in the email. | 16:47.28 |
| chrisl | I'm sure someone will forward it to Miles, and he'll raise the subject | 16:48.33 |
| Robin_Watts | I've just replied and copied them on to Miles. | 16:51.04 |
| | kens: There are several such "Perpetual licensees". | 16:51.23 |
| kens | Yep, I knew fo their existence | 16:51.31 |
| kens | was merely amused | 16:51.52 |
| Robin_Watts | "how hard can it be?" <hands over money> "oh. my. god" | 16:52.29 |
| kens | :-D | 16:52.43 |
| Robin_Watts | tor8: How far off pushing the drop branch are you? | 17:09.12 |
| | We have 3 weeks before the staff meeting. Presumably we're wanting to get all this stuff in and fixed up (with the platform builds etc) before that ? | 17:10.15 |
| tor8 | Robin_Watts: could go in now, I've rebased it on top of the changes you pushed last week | 22:59.55 |
| | but I'd want to double check that it passes the cluster first | 23:00.03 |
| | I checked it last week and there were no diffs | 23:00.10 |
| | it still needs changes to lock the path/text object refcounting, remove the embedded context in pdf_csi and the pdf_process dance | 23:02.01 |
| | and I'd like to fix fz_device to use an embedded super struct rather than a user pointer | 23:02.20 |
| | hopefully I will get all that done tomorrow | 23:02.26 |
| | depending on how demotivated I'll get when I start pulling at the strings in pdf_csi... | 23:02.53 |
| | of those, I guess the fz_device is the main one to make sure to get in since that will affect the device interface | 23:03.25 |
| Robin_Watts | tor8: How 'end user-facing' is the pdf_process stuff? | 23:47.58 |
| | An embedded context in there may not be the end of the world. | 23:48.09 |
| | pdf_csi is deliberately self-contained cos there is a lot of stuff to pass around. | 23:48.44 |
| | I guess see how it goes... | 23:48.48 |
| | Forward 1 day (to 2015/02/17)>>> | |
IRC Logs
