问题标签 [directwrite]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
directwrite - 使用 DirectWrite API 的软连字符
在示例应用程序 DWriteSimpleHelloWorld 中,我呈现了一个文本
到 DWrite HwndRenderTarget
- 有效地,到我的应用程序的窗口。我DrawText
使用ID2D1HwndRenderTarget
. 我希望行为符合 ­
在 Web 浏览器中呈现包含实体(软连字符或音节连字符)的文本字符串。
如果窗口足够宽以适合呈现的短语的宽度,我会看到如下文本
但是,当我调整窗口大小以使短语的尾部无法放入窗口时,我看到:
而网络浏览器会在第一行的末尾用连字符呈现此文本:
我的目的是让用户在我的DWrite
应用程序中为长词插入连字符提示,但我看到的好像\u00AD
是一个“隐藏”的空格。
我读过关于软连字符定义和使用的微妙之处(例如,https://www.cs.tut.fi/~jkorpela/shy.html),所以我谦虚地问:观察到的DWrite
“设计”行为是? 如果是这样,如何实现在需要时在行尾产生连字符的连字符提示?
请注意,当我使用wszText_
字符串的字形索引将文本绘制为使用 方法创建的几何图形GetGlyphRunOutline
时IDWriteFontFace
,我看到一个字符串在其应有的位置包含一个连字符:
c++ - 如何在 DirectWrite 中使用默认 UI 字体绘制文本?
CreateTextFormat方法需要一个 fontFamilyName 参数。如何创建使用默认 UI 字体的 IDWriteTextFormat?
c++ - 当我使用 DirectWrite 在 GDI hdc 上绘制文本时,如何设置透明背景?
现在我正在开发一个使用 GDI 在屏幕上绘制文本的遗留产品。现在我尝试使用 DirectWrite 来绘制文本以获得更好的外观和字体的准确性。我很好奇以前有人做过吗?我遇到一个问题,当我使用 DirectWrite 在 GDI hdc 上绘制文本时,背景颜色总是白色,我需要透明背景,可以吗?看来 SetBkMode 没用
示例代码如下,
directwrite - 如何在 DirectWrite 中为倾斜字体获取正确的文本宽度?
我通过以下代码创建了一个 IDWriteTextLayout 对象,
然后通过文本度量获取文本宽度,
让我困惑的是,无论字体的样式是 DWRITE_FONT_STYLE_OBLIQUE 还是 DWRITE_FONT_STYLE_NORMAL,同一个字符串的宽度都是同一个值。为什么?我希望当字体样式为 DWRITE_FONT_STYLE_OBLIQUE 时,宽度应该更大。如何获得倾斜文本的正确宽度?
谢谢。
fonts - 为什么某些字体的字母间距在字体渲染之间有所不同,而其他字体则没有?
为什么字体渲染器处理字体的方式有如此大的差异?具体来说,为什么字母间距会随某些字体而变化而不随其他字体变化?
例如,为什么“Open Sans”在所有环境之间的字母间距几乎相同?但是“Arial”字母间距变化很大?“Arial”字体是否有一些“Open Sans”没有的元数据?
开放式 Sans,16 分
宋体,16pt
谢谢。
c++ - 我从 DirectWrite 字体文本度量中获得的字体高度与我请求的高度参数不同
谁能解释一下?
下面的代码:
This function is from a class I'm using to provide a graphics interface for Direct2D (and DirectWrite for text). The function replaces a font it is storing as the 'current' one to one of a new size, and updates a size variable for reference.
The problem is that if I pass in 16 to the function (for example), the font I am given is BIGGER than point size 16 when created using Direct2D. (Using WinGDI it produces my reference size of 16 on the screen.) The Win32 function is my benchmark, and the directD version creates a bigger font than the Win32 code.
我认为我需要将点大小输入转换为该函数,以便为 Direct2D CreateTextFormat() 函数提供 DIP 值。然后我创建一个长度为 0 的字符串的布局,以获取创建的默认字体的高度。这与我要求开始的内容不同......
我找不到任何足够详细地描述这一点的文档来解决这个问题。每个关于功能和结构的网站都只是模仿 Windows 网站关于结构内容的内容。(Grrrr !!)它实际上并没有说明文本度量函数输出是否为 DIP,我假设它是但看不到从另一种格式明显转换回 16!请帮忙 :)
谢谢
delphi - 将 TImageList 字形绘制到 TDirect2DCanvas
我目前正准备将旧组件的绘图代码从 GDI + UniScribe 替换为 Direct2D 和 DirectWrite(继任者)。
到目前为止,过渡是直截了当的,因为大多数时候我需要做的就是将对 Canvas(TCanvas 类)的调用替换为自定义 FDirect2DCanvas 实例(TDirect2DCanvas 类,来自 Direct2D 单元)。
不幸的是,当尝试从 TImageList 实例将字形绘制到 FDirect2DCanvas 上时似乎并不简单,因为 draw 方法仅适用于 TCanvas,而不适用于相当通用的 TCustomCanvas(它是 TCanvas 和 TDirect2DCanvas 的祖先)。
这种困境的解决方案是将 TImageList 字形绘制到一个临时位图并将其绘制到 TDirect2DCanvas。但是,我担心这可能会大大降低绘图性能。
到目前为止,有没有人这样做过?我有什么选择?
c# - 在 SharpDX / DirectWrite 中获取 ABC 字符宽度
在 GDI 中获取字符的 ABC 宽度(左方位、右方位等),我将调用GetCharABCWidths。
我如何使用 SharpDX 或 DirectWrite 实现相同的测量值,我是否应该期望值在这个和 GDI 之间匹配相同的字符?
到目前为止我做了什么?因缺少 Direct* 和 SharpDX 文档而迷失方向。
winapi - 如何使用 DirectWrite 平衡面向脚本的 OpenType 功能与其他 OpenType 功能?
全面披露:我正在开发我的 libui GUI 框架的文本 API。这包含了 Windows 上的 DirectWrite、OS X 上的 Core Text 和其他 Unix 上的 Pango(使用 HarfBuzz 进行 OpenType 整形)。我要指定的文本格式属性之一是要使用的 OpenType 特性的集合,这三个特性都提供;DirectWrite 是IDWriteTypography
.
现在,当您使用这些库绘制一些文本时,默认情况下您会启用一些有用的 OpenType 功能,例如标准连字 ( liga
),如 f+i 连字。我认为这是特定于字体的,但事实证明这是特定于正在成形的文本的脚本。Microsoft 为 OpenType 支持的所有脚本提供了指南(在“特定于脚本的开发”下),我可以看到在 HarfBuzz 本身中完成这一切以确认它的相当复杂的逻辑。
在 Core Text 和 Pango 上,如果我启用其他属性,它们将被添加到这些默认值之上。但特别是使用 DirectWrite,IDWriteTextLayout::SetTypography()
这样做会删除默认值:
可以在此处找到产生此输出的程序。
显然,我的第一个选择是询问如何获得 DirectWrite 的默认功能。不过,有人已经在这个网站上这样做了,答案似乎是“不”。
我猜 DirectWrite 允许我完全控制应用于某些文本的功能列表。这很好,但除非我以某种方式明确禁用默认功能,否则我无法使用其他 API 执行此操作!当然,我不知道这个列表是否会改变,所以硬编码可能不是最好的主意。
即使硬编码是一种选择,我也可以为每个脚本获取 HarfBuzz 的列表,但是 a)它相当复杂b)脚本有多种可能的整形器,这取决于(我认为)版本兼容性(例如,缅甸)。
那么为什么不使用 HarfBuzz 的列表来重新创建 DirectWrite 的默认功能列表呢?无论如何,它似乎想要对其他塑造者准确,所以这应该有效,对吧?好吧,我需要做两件事:弄清楚要使用什么脚本,并弄清楚要在脚本的哪些字符上使用哪些属性,其中字符在单词中的位置很重要。
DirectWrite 提供了一个接口,该接口IDWriteTextAnalyzer
提供了执行整形的工具。我可以使用它,但似乎脚本数据以DWRITE_SCRIPT_ANALYSIS
结构返回,并且脚本 ID 的描述说“编写系统脚本的从零开始的索引表示。”。
这没有帮助,所以我编写了一个程序来转储我输入的文本的脚本编号。在输入字符串上运行它
产生输出
我无法将这些脚本编号与任何 Windows 标头中的任何内容匹配:如果在任何 API 中定义了阿拉伯文、拉丁文或西里尔文编号,它们与这些不匹配。即使我确实得到了脚本和脚本编号之间的映射,这仍然没有给我提供应用词内特征的数据。
Uniscribe呢?好吧,等效SCRIPT_ANALYSIS
类型的文档说它的脚本 ID 是一个“[opaque] 值”,它的“这个成员的值是未定义的,应用程序不应该依赖于它的值从一个版本到下一个版本是相同的”。虽然我可以获得LANG_ENGLISH
一个语言代码来识别脚本,但除了“西方”(拉丁语?)脚本之外,仍然没有定义值。DirectWrite 值是否与 Uniscribe 相同?似乎我至少可以通过查看fLinkBefore
andfLinkAfter
字段来确定单词的初始和最终状态,但这足以正确应用每个脚本的属性吗?
HarfBuzz 确实有一个实验性的 DirectWrite 后端,它不打算被实际程序使用;我还不确定它是否具有我上面指定的相同的功能破坏。如果我发现了,我会在这里更新这部分。
最后,如果我以类似 kaxaml 的方式输入以下与上面第一个等效的测试用例:
我看到连字被正确应用,即使在后一种情况下:
(最后的分数只是为了证明该属性正在被应用。)如果我假设 XAML 使用 DirectWrite,那么这证明我的第一个选项(简单地将我的自定义属性覆盖在默认值之上)应该是可能的......(我做出这个假设的基础是 XAML 提供了一个与 Direct2D 惊人相似的 API 来绘制 2D 图形,并且填补了很多漏洞,我必须手动编写大量胶水代码才能用 vanilla Direct2D 做同样的事情,所以我假设 XAML 中的任何可能都可以通过 Direct2D 实现,并且通过扩展 DirectWrite,因为它们在技术上是一起引入的......)
在这一点上,我完全迷失了。我希望至少可以跨平台进行预测,而且我不确定程序甚至应该如何,更不用说直接使用 OpenType 功能了。我是否对文本布局 API 抱有不好的期望?如果需要,我是否必须放弃 IDWriteTextLayout 并自己进行所有文本整形和布局?
还是我必须放弃普通 Windows 7 支持并升级到平台更新 DirectWrite 功能集?甚至完全是Windows 7?
c# - 使用 system.drawing / directWrite 时如何设置字体粗细。
TLDNR:现在是 2017。使用System.Drawing.createfont时如何设置字体粗细
更长的版本:在 GDI32 下,我将创建一个设备上下文,填写一个 LOGFONT 结构,包括一个重量值,如 400,500,600 等,并创建字体。字体映射器将运行一个算法来将我的请求与系统上可用的最佳匹配字体相匹配,并返回一个句柄。
在 system.drawing 下,字体构造函数有 13 个重载,但没有一个具有明显的权重。有一个 FontFamily 参数,但唯一的权重效果是添加一个二进制“粗体”选项,这与设置所需的字体粗细不同。
为什么这很重要:字体有家族和重量变体。重量是字母的粗细或暗度。在排版中,如果我需要半粗体字体,那么我真的必须得到半粗体版本的字体,假设它安装在运行代码的机器上。
到目前为止我做了什么?通过谷歌、SO 和 MSDN 进行了大量基于网络的研究。在我写这篇文章时,我查看了所有建议的问题。到目前为止,我还没有找到前进的方向,而我正处于那个时候,你知道你在问错误的问题,并在寻找能指引我回到正确方向的人。
在 GDI 下是可能的 - system.drawing equiv 是什么。
编辑:这个问题来自一个实际使用directWrite(dw)的当前项目,而不是system.drawing。但是要求之一是知道请求的字体可用。使用 GDI32 思维方式,在 dw 中似乎没有明显的解决方案,因此我们转向 system.drawing,问题就出现了。
在对这个问题的初步回应评论引发了更多研究之后,我们有了一个启发性的时刻。这是在 dw 中请求字体的方式与 GDI32 完全不同。dw使用字体族/粗细/宽度/斜率字体模型进行字体匹配。它还使字体系列变体枚举变得容易。
我们来自一个遗留用例,其中我们的数据包括 GDI32 字体名称。这通常是姓氏,但各种字体铸造厂以不同的方式使用它,如果你有像TypeTool这样的字体内部工具,你可以观察到这一点——一个铸造厂可能将他们的粗斜体版本称为“MyFont Bold Italic”,而另一个将他们的称为“MyFont” ' 并将粗斜体说明符保留在其他字体参数中。
与此同时,Windows(至少是 Windows 10)似乎已经更新了它在安装时映射字体的方式,识别蹩脚的名称并将其作为一个家族呈现。MS Office 似乎没有加入这种方法(例如 PowerPoint 字体选择列表中的蹩脚名称),但如果您浏览 Windows/fonts 文件夹,您可以看到它。
现在,这一切都非常好,但是如果您只使用旧版 GDI32 字体名称并尝试在 dw 中实例化字体,它将失败。解决方案似乎是对 GDI32 字体名称进行预处理,以去除粗细、宽度和斜率枚举词。完成后,dw 将匹配您的字体。
这种方法在初始测试中似乎非常可行,而且当字体确实不存在时,我们可以轻松返回一些丑陋的默认值,例如“Courier”,此外,如果我们想要选择,我们可以廉价地获得字体家族成员的列表如果所需的成员不存在,则另一个成员(我知道如果我们走这条路,我们倾向于重新发明字体映射器)。
结论:dw字体命名与GDI32不同。您可能在 GDI32 中使用的更奇特的字体名称不能保证与 dw 一起使用,并且需要按摩成 dw 格式,但它是可行的。
我稍后会更新上述方法的结果。