-
-
Notifications
You must be signed in to change notification settings - Fork 562
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow rendering of glyphs directly #61
Comments
Thank you for your proposition. Can you please describe exactly what problem this feature solves? As far as I understand, QuestPDF needs to offer better text capabilities in future releases. Including font subsetting (to minimize final PDF size), text shaping and font fallback. Each of them is a difficult topic, not to mention it touches the most complex part of the library 😀 But, assuming that all three mentioned features are available, do you still have a use-case for the
The layouting engine used in QuestPDF is a multi-pass algorithm. It is needed to support page-related features (e.g. printing a total number of pages on each page). Therefore, all elements in the document need to exist in the memory during the entire rendering process. From this point, I am not sure if the |
The problem I'm trying to solve is font fallback. For content that where we are unsure of what typeface needs to be used, we cycle through each character in the string, calling This results in an array of pairs (of typefaces and glyphs) which we want to render. Since we already know which typeface and which glyphs we want to render, it's easier if we pass that directly to QuestPDF to render. Because we have one large array of glyphs ( Speaking to the larger issues, if QuestPDF had some sort of font fallback mechanism, we wouldn't need this; however, I understand that font fallback is a tricky subject and don't expect that feature, as we have a mechanism to handle this now. Of course, if you feel the fallback feature is the more appropriate feature (over |
I think that font fallback is more appropriate than the Glyph feature as it covers the problem for more users. There is no such functionality at this moment but I am well aware that it should be added at some point. Right now, you can use the If you can share your code for font fallback implementation, it will help me start with this feature in the future 😁 I often have many experimental branches where I test new functionalities way before making them public. |
@MarcinZiabek Warning, wall of code incoming:
Basically, we load So the overall time is |
Thank you! I will analyse this code and hopefully, it would be a great foundation for this feature 😁 I really appreciate your help in this regard. |
I'm currently working with QuestPDF to try and render PDFs that may contain multiple languages.
These documents are dynamically generated from external content outside of my control, so I won't know the characters/languages that are needed, but I have a good idea of what combinations of fonts can be used to provide the coverage I need.
That said, can use SkiaSharp to get the font information and provide fallbacks by querying for glyph support in the fonts that I have.
This means that I'll have different array of glyphs, each which I'd like to render using a different font.
What I'm looking for from QuestPDF is a way to be able to pass an array of
ushort
(or whatever you feel is appropriate) representing the glyphs of a font to render.Something analogous to
Text
, like so:As well as an overload that takes a descriptor, like
Text
:The font used would be whatever is specified in the
TextStyle
or the global font (i.e. normal font fallbacks are used although often, I would be specifyingTextStyle
to indicate the font to use).I should also note that what would help in this process is to add overloads taking
ReadOnlySpan<ushort>
as we'll probably have an array of glyphs which we'll want to send subsections of without allocating new arrays (also, in general, overloads ofText
which takeReadOnlySpan<char>
would be great as well).The text was updated successfully, but these errors were encountered: