I've trouble using the prince-hyphenate-patterns property. I'm using OpenOfiice dictionary "en_US.dic" for hyphenation as follows.
div { font-family: serif; font-size: 11pt; line-height: 14pt; text-align: justify; hyphens: auto; prince-hyphenate-patterns: url('en_US.dic'); } (where 'div' is my root element in xhtml and the dictionary is in the same location as the source CSS & xhtml file)
The output PDF does not have any effect on hyphenation. It comes out as an unhyphenated PDF with no hyphenation at all.
That pattern syntax looks different to what we are using, but I was unable to download the file to see as it keeps timing out. Are you sure that's a hyphenation dictionary and not a spelling dictionary of some kind? Or perhaps it's just a different format.
I'm having trouble again with prince-hyphenate-patterns.
When I use "prince-hyphenate-patterns: url('en_US.dic');"; this works great and all fine but when I change the path to an absolute url like "prince-hyphenate-patterns: url('http://IP/folder/en_US.dic');" prince throws an error: can't open input file: No such file or directory
I checked though, the file is available on the mentioned path.
Can you help me on this or am I being stupid here :? ?
We are working on supporting this on DocRaptor to allow more automatic patterns. One thing that I have run into is if I define the pattern to use for a language in the hyph.css file, and then done use prince-hyphenate-patterns for that language, everything works as expected. As soon as I attempt to use prince-hyphenate-patterns, it does not. Perhaps I am using the wrong local file system path, but trying to match the stuff on https://www.princexml.com/doc-prince/#hyphenation and https://www.princexml.com/doc-refs/#prop-prince-hyphenate-patterns is not working ( url("hyph-ta.pat") ).
Making this take absolute HTTP URLs would be a nice enhancement, but ultimately I think the base function may have issues or need documentation updates since it doesn't seem to work in prince 12. When I say it doesn't work, I mean I go from having a line in my log about using hyph-ta.pat to nothing, not even a fallback which I would think it would use if the file I was requesting was not findable.
Joel, it might be superfluous to ask - but did you make sure to turn on hyphenation with "hyphens: auto;" ? Maybe it needs to be better emphasized in the documentation...
I tried using a downloaded hyphenation pattern, and it worked as expected.
Yeah, I have tried hyphens in a couple places and it is required to pickup the automatic setting of the hyph file via hyph.css so I don't think it's that.
It is needed to turn on (automatic) hyphenation (as opposed to manual hyphenation, which only hyphenates when there are characters such as e.g. "soft hyphens", represented either by the Unicode character U+00AD or the HTML entity ­ ). So just declaring prince-hyphenate-patterns is not enough, also hyphens needs to be set to auto. prince-hyphenate-patterns just tells Prince which hyphenation pattern dictionary to use for the automatic hyphenation.
Yes I know. I was using it in the file I was testing. I have a working automated test in DocRaptor that uses it. The problem is as soon as I add the prince-hyphenate-patterns for the language-in-question's hyphenation, or at least logging about the use thereof, stops working.
Odd, I tried downloading the Dutch .pat file from the CTAN archive, then run the attached file - both files in the same directory. It works as expected for me.
We're running in a hosted environment. It's not practical to put pat files into the same directory.
But, you have rubber ducked me to understanding why this isn't working. Our content files go into a DMZ which is not nearly the same structure as prince's, so my assumption was if I gave prince-hyphenate-patterns a file URL, it would check the DMZ and then the sudo-FS that is the prince directory structure. The latter is not true here. SO yeah, we can do automatic languages in our context but not support the css property without using absolute http URLs.
Making this take absolute HTTP URLs would be a nice enhancement, but ultimately I think the base function may have issues
So, yeah, I guess that it would be a nice enhancement to have support for absolute HTTP URLs - since that seems to be the issue of the base functionality!
