| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Imagemagick does not generate svg images very well, but it can convert
them to png quite well.
For browsers that don't yet support displaying svg, this also provides a
workaround; just scale the svg down to get a png. But the workaround is
partial, since scaling the image larger, or leaving it the same size will
cause the original svg to be displayed. Since browsers are actively
improving svg support, this is good enough for me.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Particularly important for floating images, which could before be placed
uncomfortably close to text.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This way users can use all the other alignment values when not including a
caption. Also, it will work without the standard style, and I don't have to
worry about regressions this way.
|
| |
|
|
| |
Only exists as an undocumented backwards compatability hack.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is achieved by preparing CSS definitions that emulates the behavior
of the align attribute, and passing it to the outermost IMG wrapper
(A or TABLE) instead of passing the align value to IMG directly.
|
| | |
|
| |
|
|
|
|
|
|
| |
I had assumed that an image shown full size did not need add_depends, since
a change would not need a change to the displaying page.
But this is not true if the image is modified and its size changes. Then
the page needs to update its img tag to reflect the current size.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an image was resized smaller, with width and height specified to values
that did not fit its aspect ratio, the image tag with/height were not
adjusted to the actual size imagemagick chooses.
This was broken by 03449610d6c666ba24bea68f01d896613e522278.
To fix it right, it unfortunatly needs to always read the src image now,
in order to determine if the image is being displayed larger, or resized
smaller. When resized smaller, it then always uses the size of the
thumbnail, while for larger it calculates the size.
(Only way to get rid of this sometimes extra image read would be to change
it to not allow displaying images larger.)
|
| |
|
|
|
|
|
|
| |
either dimension.
Although imagemagick handles even really large sizes sanely, using a page
file, doing so would just waste time and disk space, since the browser
can be told to resize it larger.
|
| |
|
|
|
|
|
| |
Previously, [[!img bar.jpg]] on foo, where foo/bar.jpg exists, would
get a dependency equivalent to "glob(bar.jpg)" (which might not match
anything), rather than the correct "glob(foo/bar.jpg)".
(cherry picked from commit 85b2ec49ecd12dd23e5c432933457a72744ce7cb)
|
| |
|
|
|
|
|
|
|
| |
This was impressively broken. add_depends was being called with params
backwards, and on parameter was set to the name of the generated
file, which isn't in the source.
Now updates to images will update the page that contains them, thus
updating them. This is unncessary for fullsize images, so skipped.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is sorta an optimisation, and sorta a bug fix. In one
test case I have available, it can speed a page build up from 3
minutes to 3 seconds.
The root of the problem is that $links{$page} contains arrays of
links, rather than hashes of links. And when a link is found,
it is just pushed onto the array, without checking for dups.
Now, the array is emptied before scanning a page, so there
should not be a lot of opportunity for lots of duplicate links
to pile up in it. But, in some cases, they can, and if there
are hundreds of duplicate links in the array, then scanning it
for matching links, as match_link and some other code does,
becomes much more expensive than it needs to be.
Perhaps the real right fix would be to change the data structure
to a hash. But, the list of links is never accessed like that,
you always want to iterate through it.
I also looked at deduping the list in saveindex, but that does
a lot of unnecessary work, and doesn't completly solve the problem.
So, finally, I decided to add an add_link function that handles deduping,
and make ikiwiki-transition remove the old dup links.
|
| |
|
|
|
|
| |
if suitable alternate text is unknown, then it should not be given.
empty alt text is suitable mainly for purely decorative images.
(cherry picked from commit 3cd7f67f0cf894f4fd5ba16f68e82e4f7bdbfdc5)
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
too many plugins.. brain exploding..
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
I think this used to be a fatal error, not just inline error, so I don't
know why it was never noticed, but if a page that an img directive mentions
gets deleted, bestlink() returns a file that no longer exists, and
srcfile() throws an error.
Note that bestlink's behavior of returning a deleted file could be
considered buggy. But, if it's changed to not do that, the page with the img
on it is not updated at all when the file is removed.
|
| | |
|
| |
|
|
|
| |
Since perlmagick is not a hard dep, and goodstuff is enabled by default,
imgs should not crash builds
|
| |
|
|
| |
class and id too.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
destpage does not normally need to be worried about when creating other files
as part of the process of rendering a page. Using destpage results in
inlined pages creating two copies of such files. It works to not use destpage
in this case because the inlining page depends on the source page, so if the
source page is modified or deleted the inlining page will be updated.
|
| |
|
|
|
|
| |
set to the destination page. This avoids need for hacks to munge the urls
in preview mode, which fixes several bugs.
* Several destpage fixes in plugins.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Slight overriding of link, as link=no is still used to disable the linking
entirely. Unless you have a page named "no"..
|
| |
|
|
| |
Nis Martensen. Closes: #433188
|
| | |
|
| |
|
|
| |
through the img plugin. Also allow the id attribute to be passed through.
|
| |
|
|
|
|
|
|
|
|
| |
old files.
* Change where the img plugin puts scaled images. It's better to make the
scaled images subpages of the page that embeds them, rather than putting
them alongside the original image, since if two pages scale the same image
the same way, this prevents complications in dealing with two pages
creating the same file. The move will be handled transparently, though you
might want to rebuild your wiki to make it occur in one step.
|
| | |
|
| |
|
|
| |
always be tracked correctly.
|