Replies: 2 comments 1 reply
|
Thanks for the clear report - confirmed, and it is a regression from SE4. The renderer only read the Fixed in #14477: |
0 replies
|
Thank you very much |
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Description
When exporting to Blu-ray sup (image-based export), the inline
<font face="...">attribute set in the main editor is not applied. Every line is rendered with the single
global Font name chosen in the export dialog.
By contrast, the inline
<font color="...">attribute from the same tag IS honoredper line. So the two attributes of one
<font>tag are treated inconsistently: color isapplied per line, typeface is not.
The result is that it's impossible to mix typefaces in a single .sup that reflects the
source formatting — the font must be re-selected manually for each group of lines in the
export dialog, even though it was already defined in the edit view.
Steps to reproduce
<font color="#B6AA5C" face="Papyrus">Line A</font><font color="#9B9B9B" face="Tahoma">Line B</font>Expected behavior
Each line is rendered with the typeface declared in its own
<font face="...">tag,matching what the main editor shows. The global Font name acts only as the
default/fallback for lines that have no
faceattribute — i.e. consistent with howcoloris already handled per line.Actual behavior
All lines are rendered with the global Font name from the export dialog. The per-line
face=value is ignored (a line taggedface="Papyrus"is rendered in Tahoma). Thecolor=from the same tag is applied correctly, which is inconsistent.Workaround
Manually select the relevant lines in the export list and set the font for each group
before exporting.
Environment
Screenshots attached: edit view (with


face="Papyrus") vs. export preview (rendered inTahoma).
All reactions