This wasn't necessary before since the internal representation of
folds is be checked for consistency after each commit, but after the
switch to extradata fold operations would leave the extradata in an
invalid state. This isn't technically a problem, but it does leave more
extradata entries lying around than necessary, and it can trip up
automation scripts that aren't prepared for inconsistent fold state.
This makes the internal juggling of fold data even more complicated, but
it has a number of advantages:
- Folds will preserved even when opening the file with Aegisub builds
that don't know about folding.
- Folds will be preserved by automation scripts that re-insert every
line.
- Folds do not break when adding or deleting lines in a text editor or
some other editor, as long as the lines involving folds aren't
touched.
- In particular, merging changes using tools like git will not break
folds.
- Copy/pasting folds also keeps the folds to some extent. This is
impossible to solve in full generality, but simple cases like
cut/pasting a folded section somewhere else work, as long as the file
isn't saved in between.
- This will give automation scripts full access to folding without
needing to set up any additional API functions.
This way, automation scripts won't nuke the fold data on any lines they
modify.
This is done as userdata for now, so scripts that don't know what
they're doing don't break the folds even further. If scripts get more
access to folds, it should be with a safer and simpler API.
Line folds are managed using metadata of AssDialogue elements, and
saved in the project properties. They only affect the appearance of the
subtitle grid, and have no impact on other line operations.
Since ASS rendering depends on the storage size of the video libass
needs to know about it to render the subtitles correctly. If it isn't
told about the storage size libass uses the value from PlayRes{X,Y} as
a guess, but this isn't always correct.
With Aegisub currently always rendering at storage resolution
this ends up the same as the frame size.
* [mac/build] update build steps
* [macos] bundle app
* [macos] build dmg
* [ci] setup macOS CI
* [i18n] TODO: rm WX locale files
* [deps] set main branch to main
* Fix osx-fix-libs.py
Create symbolic links, to make libicu happy
Rewrite the script in python3, as python2 is deprecated
* Add write permission before install_name_tool when doing osx-bundle
Fixwangqr/Aegisub#39
* Handle @loader_path in libboost on macOS
See wangqr/Aegisub#39
* [tools/mac] use python3
* [ci/mac] install & using system deps
* [ci/win] don't build fribidi:docs
* [ci/mac] trying openal-soft
* [ci/mac] use pulseaudio in CI
* [ci/win] only run aeg's test
* [ci/win] fix CI
* [ci/win] fix CI: not use dict `{}`
* [ci] run ci
* [ci/win] don't build docs
* [ci/win] remove args tail newline
* [ci/win] false->disabled
* Use md title format
Co-authored-by: Ryan Lucia <ryan@luciaonline.net>
* Recover file permissions.
* [ci/win] disable fontconfig
Co-Authored-By: Ryan Lucia <ryan@luciaonline.net>
* [ci/win] disable libass:fontconfig
Co-authored-by: wangqr <wangqr@wangqr.tk>
Co-authored-by: Ryan Lucia <ryan@luciaonline.net>
Previously, margins were clamped to 0..9999, but negative margins are
well supported by most renderers. In addition, previously lua
automations automations were able to produce these negative margin
values, and they would be saved correctly. However, re-opening the file
would clamp the values, and they could not be edited in the edit box.
This commit changes the clamping to be -9999..99999, and allows entering
(and editing) negative values in all relevant fields. In addition, this
makes the subtitle edit box margin fields take 5 characters instead of 4
to accommodate negative numbers up to 9999 (also the reason for raising
the upper bound).
I haven't checked whether reverting this breaks IME input, and if it doesn't what changed on wx's end. However, this is the commit that uses private symbols, and so reverting it lets us build against upstream wx. Even if this is a loss in functionality, for now it's fine.