之前有没有人看过这个页面,来自Chromatic.io?
http://www.chromatic.io/FQrLQsb
他们的画廊很完美。我想实现同样的目标。我现在主要使用他们在GitHub上提供的linear-partition.js文件。
Johannes Treitz在这里写了一篇关于它的博客文章:
https://www.crispymtn.com/stories/the-algorithm-for-a-perfectly-balanced-photo-gallery
我的图像分割完美。它给每张图像的重量也很完美。我已经能够通过使用与彩色完全相同的标记和相同的原始图像来测试值。通过在我的窗口和他们的窗口之间切换,我可以看到分区值是相同的。
结果页面显示我的图像太大了,因为行中的最后一个图像正在下降到下一行并导致蝴蝶效应进一步沿着画廊向下看起来很糟糕。
然而,在我width / height
计算图像宽高比的地方,Chromatic.io显然正在做其他事情。 531 x 800 的图像产生的纵横比 0.66375 。虽然他们正在计算宽高比服务器端,但他们正在 0.6645454545454546 。我无法理解他们是如何达到这个数字的。他们在算法中加入了什么来获得这个数字?
这同样适用于他们的风景图片 800 x 531 。我得到的宽高比与他们不同,而且他们获得了不同的宽高比(+ - 0.002两种方式),但他们所有的风景图像都是相同的。
我为这个相当冗长的代码咬道歉,但可能是我做错了什么,所以对于任何知道如何工作的人来说,这里是:
$(window).load(function () {
var p = $('.photo');
$(p).each(function ()
{
var h = $(this).find("img").height();
var w = $(this).find("img").width();
$(this).attr({ 'data-aspect-ratio': w / h });
});
var photos = p.toArray();
var viewport = $('.images').width();
var ideal_height = parseInt( $(window).height() / 2 );
var summed_width = photos.reduce(function(sum, img)
{
return sum += $(img).data('aspect-ratio') * ideal_height;
}, 0);
var rows = Math.round( summed_width / viewport );
var weights = photos.map(function (img) {
return parseInt($(img).data('aspect-ratio') * 100);
});
var partition = linear_partition(weights, rows);
var index = 0;
for( var i in partition )
{
var summed_ratios;
row_buffer = [];
for( var j = 0; j < partition[i].length; j++ )
{
row_buffer.push(photos[index++])
}
summed_ratios = row_buffer.reduce(function (sum, img)
{
return sum += $(img).data('aspect-ratio');
}, 0);
for( var j = 0; j < row_buffer.length; j++ )
{
var img = row_buffer[j];
$(img).width( parseInt(viewport / summed_ratios * $(img).data("aspect-ratio")) );
$(img).height( parseInt(viewport / summed_ratios) );
}
}
});
答案 0 :(得分:2)
我找到了解决方案。事实上这非常简单。算法和代码是现货。事实证明,图像在所有方面都有2px的余量,代码考虑到了这一点。这意味着每张图像的宽度为4px,导致溢出。为了解决这个问题,我只做了以下几点:
Create Proc [ProcedureName]
@ID As int
As
SELECT * FROM STUDENT WHERE STUDENT_ID=@ID
通过检索CSS已分配给每个图像的边距并将其从计算出的宽度中移除,一切工作正常:)