point pixel DPI

探讨了HTML页面在不同显示器上预览与实际打印尺寸的差异,解析了px、pt及DPI之间的换算关系,并通过调整系统DPI实现预览与打印尺寸的一致。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一直没弄清过这几个跟分辨率有关的概念,直到我的膝盖中了一箭……

因为最近要用html制作要打印的表格,开始纠结改用px还是pt作单位。最后选择了pt,因为做这玩意就是用来打印的,1英寸72pt,绝对单位最清楚。

可是屏幕显示的预览页边距和实际打印的不一样,问题在于,宽度究竟应该是几何?

A4纸,宽度8.27英寸,595pt。预览界面肯定不能用595px,px往往不等于pt。那他们之间的比例是多少?已知windows的DPI(暂以为和打印的DPI是一个概念)是96,所以1px等于0.75pt。所以界面宽度应该是793px。但是测试结果表明还是不对。由于平时用多显示器,知道不同尺寸显示器的像素物理尺寸是不同的,所以屏幕显示的尺寸对应物理尺寸应该还有一个系数。计算14英寸(水平分辨率1366)的宽度为12.2英寸,对应DPI应该是112。显然windows的96与其不吻合。看到一篇文章,说系统设置应该选取和显示器的实际DPI最接近的值,但是系统给的几个选项不一定是相等的,只是比较接近。于是手动调整系统DPI为112,此时预览界面终于和A4纸一样宽了,QPringPreviewDialog显示比例100%时也和纸张等宽。但是这个显示器DPI设置让我很不适应,又改回96。此时,自制的预览界面仍和A4纸等宽,但QPringPreviewDialog调成100%时不和纸张等宽了,要调成117%才行。112/96=117。看来windows的DPI应该从缩放比例的角度来理解,而不是绝对尺寸。只有当设置的DPI等于面板的实际DPI时,屏幕才能完全反映文档尺寸,否则很多情况下都要通过缩放来解决。

另外,明明都是A4纸的宽度,为什么QWebView显示的比QPringPreviewDialog要大一些?算了,反正打印出来是对的就行了

本文含有一些对事实的描述,但并未形成明确的结论,因为对这些算术问题实在是懒得纠缠……欢迎有兴趣深究的朋友留言指教大笑

基于数据挖掘的音乐推荐系统设计与实现 需要一个代码说明,不需要论文 采用python语言,django框架,mysql数据库开发 编程环境:pycharm,mysql8.0 系统分为前台+后台模式开发 网站前台: 用户注册, 登录 搜索音乐,音乐欣赏(可以在线进行播放) 用户登陆时选择相关感兴趣的音乐风格 音乐收藏 音乐推荐算法:(重点) 本课题需要大量用户行为(如播放记录、收藏列表)、音乐特征(如音频特征、歌曲元数据)等数据 (1)根据用户之间相似性或关联性,给一个用户推荐与其相似或有关联的其他用户所感兴趣的音乐; (2)根据音乐之间的相似性或关联性,给一个用户推荐与其感兴趣的音乐相似或有关联的其他音乐。 基于用户的推荐和基于物品的推荐 其中基于用户的推荐是基于用户的相似度找出相似相似用户,然后向目标用户推荐其相似用户喜欢的东西(和你类似的人也喜欢**东西); 而基于物品的推荐是基于物品的相似度找出相似的物品做推荐(喜欢该音乐的人还喜欢了**音乐); 管理员 管理员信息管理 注册用户管理,审核 音乐爬虫(爬虫方式爬取网站音乐数据) 音乐信息管理(上传歌曲MP3,以便前台播放) 音乐收藏管理 用户 用户资料修改 我的音乐收藏 完整前后端源码,部署后可正常运行! 环境说明 开发语言:python后端 python版本:3.7 数据库:mysql 5.7+ 数据库工具:Navicat11+ 开发软件:pycharm
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值