| | <<<Back 1 day (to 2019/06/08) | Fwd 1 day (to 2019/06/10) >>> | 20190609 |
| ldiamond | Anyone here have an idea why I get this error from ps2pdf "DEBUG: FC_WEIGHT didn't match" | 16:30.11 |
| | I'm guessing this is related to ghostscript | 16:30.30 |
| | I get that when converting a .ps file generated with `enscript` and setting a custom font. | 16:30.56 |
| | My goal is to print a text file using a different font (OCRA) | 16:31.21 |
| camelopard | ldiamond: This is a debug message that can be ignored. It is produced by FontConfig that enumerates fonts and explains why some of the fonts are rejected. | 16:42.06 |
| ldiamond | The output file does not use the right font though | 16:42.59 |
| camelopard | Do you have this font anywhere on your system? | 16:43.46 |
| ldiamond | yes, I placed it in /usr/share/enscript/afm/OCRA.afm, added it in the font.map, added it to ~/.fonts/ as well as /usr/share/fonts/TTF/OCRA.ttf just to be sure | 16:44.46 |
| | fc-list shows all of them (except for the enscript one) | 16:45.06 |
| | my understanding is that enscript doesnt use fontconfig | 16:45.19 |
| camelopard | AFAIK enscript just generates PostScript files. Please check whether Ghostscript can find this font. | 16:48.37 |
| ldiamond | yes it's a postscript file that's generated. How do I check if Ghostscript can find it? | 16:49.25 |
| | I thought ghostscript used fontconfig | 16:49.36 |
| | $ fc-match OCRA | 16:49.41 |
| | OCRA.otf: "OCRA" "Regular" | 16:49.43 |
| camelopard | gs -c /FOO findfont | 16:49.59 |
| | gs -c /OCRA findfont | 16:50.20 |
| ldiamond | Loading OCRA font from /home/ldiamond/.fonts/OCRA.otf... 4456072 2768357 6108924 4744828 1 done. | 16:51.04 |
| camelopard | OK, Ghostscript can find this font. Now we need to figure out what font your file is trying to load. | 16:52.49 |
| ldiamond | I piped my postscript file to that gs command you gave me | 16:53.28 |
| | I see this, Loading OCRA font from /home/ldiamond/.fonts/OCRA.otf... 4456072 2768357 6108924 4744828 1 done. | 16:53.47 |
| | followed by a bunch of GS<> stuff but then : Substituting font Courier for HF-gs-font. | 16:54.14 |
| | and Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.27/Resource/Font/NimbusMonoPS-Regular... 4550016 3040058 6189724 4828841 1 done. | 16:54.32 |
| camelopard | Your file is trying to use "HF-gs-font". | 16:55.49 |
| ldiamond | here's what's generated by enscript: http://ix.io/1LkU | 16:59.22 |
| camelopard | OK | 16:59.32 |
| ldiamond | it does include `/HF /HF-gs-font findfont [HFpt_w 0 0 HFpt_h 0 0] makefont def` but also a reference to OCRA | 17:02.48 |
| camelopard | Yes, the file looks fine. Where can I get the OCRA font? | 17:09.08 |
| ldiamond | I first googled it and found a copy, but the copy I use right now is from https://aur.archlinux.org/packages/ocr-fonts/ | 17:11.19 |
| | more specifically https://jaist.dl.sourceforge.jp/tsukurimashou/56948/ocr-0.2.zip | 17:11.47 |
| | it contains .afm .ttf etc | 17:13.17 |
| camelopard | ldiamond: Everything works for me when OCRA is available. | 19:57.07 |
| | ldiamond: I used PFB font from this distribution and had to fix a bug there. | 19:59.06 |
| | I decoded the PFB and changed s/##FORCE_BOLD##/false/ | 20:01.49 |
| HiddenCloud | Hello, I have a question about the implementation of reference counting | 22:04.00 |
| | not related to ghost script per se | 22:04.13 |
| | regarding the need for type information | 22:04.32 |
| camelopard | HiddenCloud: What question? | 23:30.36 |
| HiddenCloud | about implementing a reference count algorithm in a jvm implementation. I went full barebone on the object model without storing type information, now I realise this will cause premature frees if an object field looks like a pointer, is there a custom rc implementation that can work without type information? | 23:31.10 |
| | its a jvm for an embedded platform | 23:31.34 |
| | i didnt want long pause times + i went barebone object model for memory savings | 23:31.54 |
| | its for a school project | 23:32.00 |
| camelopard | You cannot distinguish a pointer from a number by the content in C. I don't know Java. | 23:40.28 |
| HiddenCloud | yes, what I was thinking was to use some elements of the mark-sweep algorithm | 23:41.31 |
| | as it's a conservative gc algorithm | 23:41.40 |
| | means if it finds a value that looks like a pointer | 23:41.48 |
| | it wont collect that pointer and assume it to be a live reference | 23:41.55 |
| | my rc implementation currently assumes its a pointer and can do a premature free | 23:42.33 |
| | first i thought deferred reference counting will solve it as it scans the stack | 23:42.50 |
| | but fields remain part of an object and those remain still a problem | 23:43.10 |
| | java only differentiates between primitives and objects | 23:43.58 |
| | i dont think using mark sweep is much of an option tho | 23:45.46 |
| | cause its fundamentally different from reference counting | 23:45.59 |
| | combining it will just be double work | 23:46.04 |
| camelopard | Why not add a data descriptor? Ghostscript does this. | 23:53.14 |
| | <<<Back 1 day (to 2019/06/08) | Forward 1 day (to 2019/06/10)>>> | |
Log of #ghostscript at irc.freenode.net.