第一部分是文字,第二部分是卡片链接,第三部分是文字的情况下如果拖动卡片调整大小会导致错位。
Hello
第一次遇到,有意思。只有这个卡片会吗,其他的卡片有类似的情况吗。
Kind Regards,
Support Team
我的设备是iPad,每个卡片都是这样,只要卡片评论区出现了文字-卡片链接-文字这种结构就会出现错位
我的文字是开了markdown输入的
刚刚再看了一下卡片链接必须是图像摘录(矩形或者套索),一旦有两段文字夹着卡片链接,中间卡片链接显示的图像尺寸就会出问题
Hello
感谢你的反馈,我们已经注意到了相关问题,会进行进一步的处理。如果后续还有什么问题,可以继续提出或者私信我。
Kind Regards,
Support Team
为啥这些显而易见的问题内部开发者都不知道呢?
这是个很常用的功能啊?感觉开发者都没有很认真地测试MR4
找到解决方案了。在粘贴卡片的URL时以纯文本形式粘贴就不会出现问题。一旦使用 markdown 格式粘贴URL就会出现问题。或者直接使用那个拖拽进行链接的功能也可以(猜测是因为这样是纯文本形式粘贴URL)。但是还是希望能够尽量修复,因为平时都是打开markdown打字的,来回切换很麻烦。我问了一下 ai 是什么原因,希望能够有帮助:
针对 MarginNote 4 中 Markdown 内嵌卡片链接渲染问题的分析
核心问题在于,当 MarginNote 4 的用户在 Markdown 格式的笔记中,将一个**“卡片链接”(MarginNote 的一种特殊对象)**以行间形式(例如:“文本A - [卡片链接] - 文本B”)嵌入时,在调整包含该笔记的父卡片大小时,该卡片链接的预览图像会与周围的文本A和文本B发生重叠和错位。
关键的对比信息是:使用标准的 Markdown 语法插入普通图片 (例如 
或 
) 时,即使图片与文本在同一行,调整父卡片大小时,这类标准图片通常能正确地随文本流重排,并不会出现上述的重叠或错位问题。
基于此对比,可以进行如下分析:
-
Markdown 引擎对标准图像的处理是正常的: MarginNote 4 的 Markdown 渲染引擎在处理其原生支持的标准图像元素(如通过
![]()
插入的图片)时,其布局、重排(reflow)和尺寸调整逻辑是基本健全的。这表明问题并非出在 Markdown 引擎的基础图像渲染能力上。 -
问题聚焦于“卡片链接”这一特殊对象的集成方式:
- “卡片链接”的特殊性: 与标准静态图片不同,“卡片链接”是 MarginNote 应用程序特有的一个功能性对象。它可能包含动态生成的预览、交互行为(如点击跳转)等,其渲染和行为由 MarginNote 的自定义代码控制。
- 自定义渲染与 Markdown 文本流的协调缺陷: 当这个自定义的“卡片链接”对象被指示要作为 Markdown 文本流的一部分(即行内元素)进行渲染时,挑战在于其自身的尺寸、定位逻辑需要与 Markdown 引擎对周围文本的布局逻辑精确同步。
- 渲染冲突点: 在父卡片尺寸发生变化时,Markdown 引擎会重新计算文本流的布局。与此同时,“卡片链接”的预览图像可能也需要调整其尺寸或位置。这里的 Bug 很可能发生在:
- “卡片链接”预览对象未能正确获取其在变化后的 Markdown 文本流中的应有空间和位置。
- 或者,“卡片链接”预览对象在更新自身尺寸后,未能有效地通知 Markdown 引擎,以便 Markdown 引擎能正确地重排其周围的文本。
- 简而言之,是 MarginNote 自定义的“卡片链接”渲染逻辑与其 Markdown 文本渲染环境在动态布局更新时的“沟通”或“协调”上出现了问题。
-
为何标准 Markdown 图片没问题: 标准 Markdown 图片的渲染路径通常更为直接和成熟。Markdown 解析器将其识别为图像后,会按照既定的规则(如HTML中的
<img>
标签类似的行为)进行处理,其尺寸和与文本的相对关系在重排时有明确的规范。而“卡片链接”作为一个外部注入的、具有复杂行为的对象,其与 Markdown 文本流的融合显然更为复杂。
结论:
此渲染 Bug 并非 MarginNote 4 Markdown 功能的普遍缺陷,也不是其处理标准图像内容的问题。它更精确地指向一个特定的集成问题:即 MarginNote 自身特有的**“卡片链接”对象**,在被用作内联元素嵌入到 Markdown 格式的文本中时,其动态布局调整(尤其是在响应父容器尺寸变化时)与周围 Markdown 文本的重排机制之间存在冲突或协调缺陷。