twinside / fontyfruity Goto Github PK

Hi,

It will be nice to have support to modify and encode fonts using FontyFruity. You can try to reuse as much as possible from ttasm.

Great library. Rasterific is really useful for me. It would be nice if the kerning table was applied to the horizontal info so that drawing text with Rasterific was properly kerned. If I have time I will attempt to add this, but it may take me a while as I'm not familiar with TTF format.

I have tried to render fonts from http://www.1001freefonts.com but usually I got this kind of error message:
"table cmap format 0 : invalid size. Failed reading at byte position 2134"

e.g.
http://www.1001freefonts.com/ubuntu_mono.font

bash-3.2$ ./Gui UbuntuMono-Regular.ttf
Gui: table cmap format 0 : invalid size. Failed reading at byte position 6278

Gui.hs:
import Control.Applicative( (<$>) )
import Codec.Picture
import Graphics.Text.TrueType( loadFontFile )
import Graphics.Rasterific
import Graphics.Rasterific.Texture
import System.Directory( createDirectoryIfMissing )
import System.FilePath( (</>) )
import System.Environment
outFolder = "."

textExample :: IO ()
textExample = do
[fname] <- getArgs
fontErr <- loadFontFile fname
case fontErr of
Left err -> putStrLn err
Right font ->
writePng (outFolder </> "text_example.png") .
renderDrawing 640 480 (PixelRGBA8 255 255 255 255)
. withTexture (uniformTexture $ PixelRGBA8 0 0 0 255) $
printTextAt font 12 (V2 20 40) "A simple text test!"

main = textExample

I reported an issue in Chart that is due to a limitation of the diagrams-rasterific backend. My understanding is that diagrams wants the origin Y coordinate of some text to be the baseline height of the rendered text, FontyFruity exposes the full string bounding box, and Rasterific's printTextAt takes the desired baseline height. I think, then, the issue is that it is not clear how to locate the bounding box returned by stringBoundingBox with respect to the baseline height given to printTextAt. What is needed to improve diagrams compatibility is the difference between the top of the bounding box and the baseline.

Thanks for any assistance!

Hey there - I'd like to release a new library to hackage that depends on descriptorOf, which is not up on hackage yet. Can you upload the current version to hackage?

Alternatively, I'll upload if you give me permission :)

Thanks!

GHC 8.8 implements the final part of the MonadFail proposal. The impact of this on FontyFruity is that the put method can no longer call fail to indicate that put is not implemented. (In turn because Data.Binary.Put.Put does not implement a MonadFail instance.)

I have raised PR #25 that addresses this issue by replacing fail with error.

I'm willing to have a go at implementing any alternative solution if this approach is not acceptable.

I believe you need to use fromIntegral instead of toFloat on these lines to get the correctly scaled offset. You can easily test by checking out accented characters like áéöÁÉÖ in Arial or Times New Roman.

Sadly, this still doesn’t seem to be enough to fix other characters, like í, but that might be related to other flags, e.g. using metrics from a different character.

Can not load http://www.1001freefonts.com/muddy_tractor.font

error message:
....
NUL\CAN\255\171\NUL\SOH\NUL\CAN\255;\NUL\STX\NUL\n\NUL\ACK\NUL\ACK\NUL\NUL\NUL\v\NUL\DC1\NUL\SOH\NUL\DC3\NUL\DC3\NUL\b\NUL\CAN\NUL\CAN\NUL\t\NUL+\NUL+\NUL\n\NUL-\NUL1\NUL\v\NUL3\NUL6\NUL\DLE\NUL8\NULE\NUL\DC4\NULT\NULT\NUL"\NUL\190\NUL\191\NUL#\NUL\NUL",4282,"table cmap format 0, invalid size: 47104")

The documentation for the latest version of this package is missing on Hackage. They've been pending on Hackage for some time, this usually indicated that Hackage wasn't able to build the package.

Is it possible for you to manually upload the package using cabal upload --doc, please?

Thanks!

Can we have functions

textWidth :: Font -> Int -> String -> Double

textHeight :: Font -> Int -> Double

Which take a font, point size (and in the case of width, string of text) and return the width and height of the string in points?

Reposting Twinside/Rasterific#8

According to stringBoundingBox the string "I am a pretty long string" has a bounding box that is smaller in height than the string "I am a pretty long string-". It seems that adding the last '-' character is causing stringBoundingBox to return a larger _yMin, which in turn makes the height smaller. Here are some renderings of the strings along with their bounding boxes (in white).

The documentation states that getStringCuverAtPoint returns a "List of contours for each char". What kind of contours are these? For instance does the inner Vector represent the bezier curves of the glyph? If so - what degree bezier curve is it?

Exposing descriptorOf will make fonts hashable without having to hash the show value of the font.
https://github.com/Twinside/FontyFruity/blob/master/src/Graphics/Text/TrueType/FontFolders.hs#L185

I'm not completely sure of this one but I think that FontyFruity's usafePerformIO (http://hackage.haskell.org/package/FontyFruity-0.4/docs/src/Graphics-Text-TrueType.html#getOrFail) may be causing some other IO operations to fail. I'm reading a ttf font, calling getStringCurveAtPoint 72 (0,0) [(font, 12, "0")], reading some glsl shader files, compiling those shaders and then rendering the contours with those shaders.

    Right font <- loadFontFile "/Users/schell/Library/Fonts/UbuntuMono-R.ttf"
    let cm = getCharacterGlyphsAndMetrics font '0'
        vs = getStringCurveAtPoint 72 (0,0) [(font, 12, "0")]
        bs = fontyToBeziers vs
    print cm
    bezr <- newBezRenderer window bs

Everything works fine until I change to getStringCurveAtPoint 72 (0,0) [(font, 32, "0")] at which point my shaders can't compile because of a syntax error. I can alternatively add an extra line to the end of my fragment shader which fixes this problem, but it seems that something is not quite right. I know the shaders are correct and I'm guessing that somehow trash bytes are being read by opengl.
Deleting "print cm" or inserting other IO has unexpected effects as well.

buildCache is failing about half the time I call it at the beginning of my app. Here is the exception:

/Library/Fonts/Telugu Sangam MN.ttc: openBinaryFile: resource exhausted (Too many open files)

The exact font it errs on is different (almost) every time. I'm running on Mac OS X 10.11.2 and ghc 7.10.2.

Since the glyph mapping tables are sorted according to format only, there’s no guarantee that the Unicode translation will be preferred when interpreting a character code. One example is this font, where code points below 256 are picked up by the wrong table (PlatformMacintosh), and many other fonts yield the exact some undesired result.

Probably the easiest solution would be to consider the platform when sorting the character maps for findCharGlyph and make sure the Unicode mapping ends up being the head of the list.