记录前端菜鸟的日常——Pdf.js与双指缩放

记录前端菜鸟的日常——Pdf.js与双指缩放

一、需求

这两天一直在研究这个,之前项目用的是vue-pdf,但是pdf打开速度巨慢。我们的需求是从上到下滑动展示,要求打开时间不能过长并且可以实现双指缩放。

1.vue-pdf(快速集成)

(1)“全量串行”,要把整个pdf全部下载并解析完之后一页一页渲染出来,渲染出来之前的页面就是一直白屏的。

(2)占用浏览器主线程,与Vue组件竞争资源。

2.pdf.js(高性能、全功能)

(1)“流式并行”,一边加载一边渲染,而且是视口在哪就优先加载哪页、智能加载相邻页,远离视口的进行销毁或者低分辨率预览。

(2)使用Web Worker在独立线程解析PDF,主线程释放。

二、PDF.js的使用

pdf.js不需要安装依赖,直接去官网下载包,这个包就是个阅读器软件(网页版),2.多版本更稳定。

里面的web文件夹就包含了html、css、js,直接扔进puclic里,一个是因为不会被压缩,而且可以直接在根目录下访问,不用走路由之类的。

这个时候你就可以进行尝试在public下放一个测试的pdf,通过/web进行访问了,以我本地代码为例,访问的是http://localhost:1357/web/viewer.html?file=/test.pdf

file放的是你要访问的pdf链接,我们的项目进入pdf.vue会向后端请求一个链接,在pdf.vue用iframe标签直接展示这个链接即可。pdf.js会自带查找关键字、旋转等功能,但是发现这个方法不能进行双指缩放。(电脑本地可以,小程序不行)

三、双指缩放

然后我就开始排查是pdf.js在手机上会被限制还是小程序的限制或者iframe不允许手势操作。

1.最开始排除的是小程序的限制

因为在微信浏览器打开那个链接也不允许双指缩放,然后开始调整pdf.js的源码,看有没有对移动端做手势限制的代码。

主要找的是viewer.js,修改点(1)webViewerTouchStart放开事件源头

这段阻止了多指触摸

修改点(2)GrabToPan解除拖拽模块的拦截

如果是触摸事件且多点触控,让他直接return 不要进行后面的event.preventDefault();将事件掌控权交给浏览器处理进行缩放。

2.排查小程序oriframe的限制

这样调整完之后发现在web/viewer.html的pdf链接微信浏览器已经可以进行双指缩放了,不过小程序还是不行,本来以为是小程序又做了什么限制,后来无意中在手机上访问/web/viewer.html和#/pdf?type=https、、、、

发现原来是/web在微信浏览器就可以,#/pdf的还是不行,于是将pdf.vue文件进行修改,不再使用iframe进行展示pdf链接,而是直接在拿到pdf链接之后进行跳转到/web/viewer.html文件,发到测试上看,果然可以了

不过需要注意的是现在我们打开的是浏览器的缩放功能,也就是上面的菜单栏会一起跟着放大缩小,不过我们的需求是不要那些菜单栏只要实现双指缩放就可以,我就在css文件将菜单栏隐藏掉了。

网上关于pdf.js在移动端双指缩放的案例比较少,大部分还要会员,阴差阳粗的实现了我们的需求而且速度也比之前快很多了,如果有大佬知道怎么只让pdf放缩菜单栏不动的话欢迎指正!

Read more

openclaw 对接完飞书群机器人配置踩坑记:消息不回、Gateway 断开问题排查

openclaw 对接完飞书群机器人配置踩坑记:消息不回、Gateway 断开问题排查

前言 用 OpenClaw 配飞书机器人,踩了两个坑:群消息不回、Gateway 总是断开。排查了好一阵子,总算搞定了,记录一下希望能帮到遇到同样问题的朋友。 发现问题 飞书消息不回复 在飞书群里 @ 了机器人,完全没反应。一开始以为是网络不好或者机器人没上线,但状态显示明明是连接着的,这就奇怪了。 Gateway 频繁断开 每次改完配置跑 openclaw gateway restart,或者根本什么都没干,Gateway 说断就断。再想启动就报错,必须跑一遍 openclaw doctor --fix 重新安装才能用。太影响使用了。 查看原因 飞书机器人 ID 搞错了 翻日志看到这么一句: receive events or callbacks through persistent connection only available in

Copilot权限设置全攻略:从入门到合规的7步落地路径

第一章:Copilot权限设置的基本概念 GitHub Copilot 是一款基于人工智能的代码补全工具,能够根据上下文自动建议代码片段。为了确保安全与协作效率,合理配置其权限至关重要。权限设置不仅影响开发者获取建议的能力,还关系到组织内代码的安全性与合规性。 权限模型概述 Copilot 的权限控制主要围绕用户身份、组织策略和资源访问三个维度展开。在企业环境中,管理员可通过 GitHub 组织设置统一管理 Copilot 的启用状态与访问范围。 * 成员角色决定是否能使用 Copilot 建议 * 组织策略可限制特定仓库禁用 Copilot * 私有代码内容不会被用于训练模型,保障数据隐私 基本配置步骤 管理员需登录 GitHub 并进入组织设置页面进行配置: 1. 访问“Settings” > “Billing and plans” > “GitHub Copilot” 2. 选择“Manage organizations”并为指定组织启用服务 3. 设定成员许可分配方式:自动分配或手动审批 API

DeepSeek-R1-Distill-Llama-8B效果展示:看看AI能写出多好的文章

DeepSeek-R1-Distill-Llama-8B效果展示:看看AI能写出多好的文章 你有没有试过这样提问:“请用鲁迅的笔调写一篇关于外卖小哥在暴雨中送单的短文”?或者“把《三体》第一段改写成适合小学生理解的科普版本”?又或者“帮我写一封既专业又带点人情味的辞职信,不卑不亢,留有余地”? 不是所有模型都能稳稳接住这些“有性格、有分寸、有温度”的请求。但今天我们要聊的这个模型——DeepSeek-R1-Distill-Llama-8B,它不靠参数堆砌,也不靠算力碾压,而是用一种更“聪明”的方式,把文字写得像真人一样自然、准确、有层次。 它不是最大的模型,也不是最贵的模型,但它可能是目前8B级别里,最会“拿捏语气”、最懂“写作分寸感”、最擅长“按需输出”的文本生成模型之一。接下来,我们不看参数表,不谈训练细节,就用最朴素的方式:直接看它写的文字。 1. 它到底是什么?一句话说清 1.1 不是“大而全”,而是“

使用 ChatGPT/Copilot 提升前端开发效率的 N 种方式

引言:AI 已经不只是副驾驶,而是你的开发团队 想象这样一个场景:凌晨 2 点,你盯着一个奇怪的 React 报错信息已经 3 小时,Stack Overflow 上所有相关答案都试过了,但问题依旧存在。这时候,你的“AI 队友”只需要 30 秒就提供了准确的解决方案,甚至解释了问题的根本原因和三种不同的修复方法。 这不是科幻场景,而是现代前端开发者正在经历的日常。ChatGPT 和 GitHub Copilot 已经从前沿技术变成了实实在在的生产力工具。但大多数开发者仅仅把它们当作“高级搜索引擎”或“智能代码补全工具”,这就像把瑞士军刀只用来开瓶盖。 今天,我要分享的是如何真正将这些 AI 助手融入前端开发工作流,让它们成为你的代码导师、调试伙伴和创意合伙人。 第一部分:代码生成与智能补全 1.1 从自然语言到可运行代码 传统方式: javascript