Felix.Li 发表于 2024-1-30 19:15
您这个情况是正常的。因为得给您说一下原理。
对于word来说，这个页眉的页数其实不是一个固定的死值，他 ...
继续测试过，有的电脑上office2021打开如果不滚动到后面去，第1页的总页数数字是不会变的，滚动到后面去再滚动到第1页，第1页的总页码就变成正确的了，而第2页的总页数一直都是正确的。
用程序读取Word转成PDF后，假如总页数是5页，PDF的第1页显示：第1页，共4页，PDF的第2页显示：第2页，共5页，第3页及后面的显示都是正确的。
所以这就是一个漏洞，请你们快点解决。
Felix.Li 发表于 2024-1-30 19:15
您这个情况是正常的。因为得给您说一下原理。
对于word来说，这个页眉的页数其实不是一个固定的死值，他 ...
我自己的电脑上用的是WPS，显示的总页数是错误的，无论是第1页还是其他页，显示的总页数都是少一页，WPS倒算了，大不了我不用它，但是Office的Word这样不好吧，因为客户们用的基本都是office？各位技术大牛，你们对Word中的xml结构应该非常精通，这个小问题应该能解决吧？
Eden.Sun 发表于 2024-1-31 11:47
AR支持直接导出PDF。如果您想用到处的word转PDF。您可以按照上面版主的回复，导出正确的wiord之后，用正 ...
AR是支持导出PDF，但是很多时候生成了Word，对Word要进行修改，如果没有这个修改的需求，我也根本不会发现这个问题。
我得给您说一下，这个不是我们错了。是office的word没有加载完。
在帖子上面给您已经回复了。
不是说你看到那个为什么会变。您其实想一下，已经导出来的东西，我们产品还能影响吗，出现这个情况的是office的word的机制。
而这个是不会影响您的转化的，如果有问题，这个您可以向office提bug。不过这个应该不会出现。
就像我上面说的，这个之所以会变，是因为word在计算自己总共有多少页，自己当前在多少页。这个操作是office在计算。而我们只是定义了这里是个变量罢了
Felix.Li 发表于 2024-1-31 18:06
我得给您说一下，这个不是我们错了。是office的word没有加载完。
你们不应该定义这个变量，而是应该在导出Word时就计算出有多少页，Word没有加载完，就导致了转换PDF就是有问题，你们好意思把自己的不作为推给微软，让微软背黑锅？
Felix.Li 发表于 2024-1-31 18:06
我得给您说一下，这个不是我们错了。是office的word没有加载完。
你们去用.NET组件Spire.word去将word转换为pdf试试看，就知道到底会不会影响转化，如果不影响转化，我会来找你们吗？
本帖最后由 Felix.Li 于 2024-2-1 09:38 编辑
这个变量不是我们定义的:
这个是我们导出来后，打开word的域代码显示的结果:
而这个变量使用时这样生成的:
也就是这个不是我们定义的，这个是我们根据word本身有的东西做计算。至于您初始看到的不一样，是因为word自己加载的时候，也需要时间。office还没有加载完。
您说的Spire.word。这个我们也确实不清楚他的加载机制是什么。但是如果从页面加载情况来看的话，他应该是word扫描一页转化一页。如果是等word加载完在转换的话，应该是没有问题的。所以不知道Spire.word有没有加载完后专门的机制
Felix.Li 发表于 2024-2-1 09:33
这个变量不是我们定义的:
这个是我们导出来后，打开word的域代码显示的结果:
你们自己试试用什么组件可以将word转换为pdf，转换保证页码不会改变。
别扯这个技术，你们的技术选型是错误的。
您好，我分别在网上找了 Aspose 和 Spire 控件做转换。
转化的是您帖子里面上传的word。测试结果
Aspose:
当前页和总页数页面显示正确。Aspose会把第二个多显示一页，Aspose会把第四页的页眉显示一页。应该是Aspose自己的机制导致。
Spire
当前页和总页数页面显示正确。并且和word一致。
测试结果起码他们都没有出现第一页是 1-2 后两页是2-3这种情况。
我的代码如下。您可以自己运行测试:
Felix.Li 发表于 2024-2-1 14:23
您好，我分别在网上找了 Aspose 和 Spire 控件做转换。
转化的是您帖子里面上传的word。测试结果
使用spire.doc加载word转换成pdf，有的时候能成功，有的时候不能成功，麻烦你们多测试几次文档。