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
QuestPDF.Drawing.Exceptions.DocumentDrawingException: 'Could not find an appropriate font fallback for the following glyphs: $U-000D ' #838
Comments
FontFallback is the font which get used when QuestPdf could not find specified character in your default font, it's my sample code i use and works fine
|
@danirzv Thanks. The exception message also includes the following text which i did not see (The VS exception popup was sized so that it did not show all the text):
|
Seeing the same and I find it perplexing since I'm not specifying a particular font family anywhere and would expect the quest to use it's default. I'm running .net8 in a Linux container. I've tried to specify a few common fonts that I believe exists on both Win and Linux but still no luck. |
I added below line. But i dont know if this is 'the way to go'. I dont like hacky workarounds, but what i dont like more are exceptions that kill my app... And there is no visual difference in my case anyway. QuestPDF.Settings.CheckIfAllTextGlyphsAreAvailable = false; |
I also encountered this problem and I'm not specifying any particular font family. For me this is due to a call to the private void ComposeHeader(TableCellDescriptor header)
{
header
.Cell()
.AlignRight()
.Text(text =>
{
text.Line("actuelle").Bold(); // <= Here
text.Span("Date").Bold();
});
} When I remove this line, it works fine. Edit : |
Thank you all for reporting this issue and sharing your feedback 😄
@eros404 Thank you for this observation. It looks like the The fix will be released soon. |
@MarcinZiabek I hope it's okay that i'm adding to this issue as i believe it is related. This is reproduceable in version 2024.3.1 Just to give you an idea of our setup. Users are writing multiline text in a windows application. The text is then stored in a database. A docker container then generates a pdf. So it's a mix of windows and linux platforms. Because input happens in windows, new line is added as I'm no expert on the subject but if i were to guess i would think that I've added a small project that can show this. Initially it will fail but if you go to MyDocument and add a space between /r/n then it will run just fine. |
Can also confirm issue with version Running / debugging in my M1 without any issue. All renders properly by default. Forcing to load a font via My FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
USER $APP_UID
WORKDIR /app
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["WebApp/WebApp.csproj", "WebApp/"]
RUN dotnet restore "WebApp/WebApp.csproj"
COPY . .
WORKDIR "/src/WebApp"
RUN dotnet build "WebApp.csproj" -c $BUILD_CONFIGURATION -o /app/build
FROM build AS publish
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "WebApp.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApp.dll"] |
Thank you for the collaboration on fixing this issue 😄 I have applied one more enhancement. Since many font files do not contain the @Krm1t Your findings have been critical. Thank you for investigating it so profoundly! Would you please test the newest 2024.3.2 version? https://github.com/QuestPDF/QuestPDF/releases/tag/2024.3.2 |
I just updated to the latest stable - 2024.3.2 and can confirm this is still an open issue. Same error as before running on a windows box with docker enabled and docker file identical to merinofg. For brevity I've left out the individual components but this will fail. I'm not explicitly adding a carriage return but assume internally that's happening.
|
Would you provide an example where you think the text.CurrentPageNumber().Format(x => /* formatting code that injects the new line with \r */); Also, are you sure that the exception is the same? Regarding the $U-000D character? |
@MarcinZiabek I'm happy it helped. That being said i can confirm that the solution seems to have helped, both in our actual application and in the test application that i attached in my earlier comment. Thanks for the quick fix. |
Hopefully this will add some more information. With the last version, I can see in the logs of the docker image the next when the exception happens:
The characters are not in order, but they should say
This is always the header of the document, with custom style as title, and as in the next image is visible, when running the The code for the component in my case looks like the next (simplified for the title, as it's where seems to fail): public void Compose(IContainer container)
{
var titleStyle = TextStyle.Default.FontSize(20).SemiBold().FontColor(Colors.Blue.Medium);
container.Row(row =>
{
row.RelativeItem().Column(column =>
{
column.Item().Text($"{title.ToUpper()}").Style(titleStyle);
});
});
} If I comment the header section, for me, the next part failing seems to be the footer where the page counter is, with the trace:
Hope this brings some more insights. |
@merinofg Indeed, it is an entirely separate problem. There is a great chance that the 2024.3.3 release fixes it. Would you please give it a try? |
Can confirm that version |
Latest 2024.3.3 solved my issue referenced above. Thanks! |
Hi,
I am trying version 2024.3.0.
But what does this error mean?
QuestPDF.Drawing.Exceptions.DocumentDrawingException: 'Could not find an appropriate font fallback for the following glyphs: $U-000D '
Is this documented? If so, i have not been able to find it.
The text was updated successfully, but these errors were encountered: